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ABSTRACT 


Despite  the  increasing  emphasis  by  the  military  on  joint  force  operations,  existing 
modelling  and  simulation  programs,  including  NPSNET,  fail  to  address  joint  operations 
and  crew  coordination.  The  problem  is  that  previous  work  on  NPSNET,  the  virtual 
environment  and  visual  simulation  platform  developed  by  the  Computer  Science 
Department  at  the  Naval  Postgraduate  School  in  Monterey,  California,  has  focused 
primarily  on  individual  ground  force  elements  with  little  emphasis  on  naval  forces  or  crew 
concepts.  This  restricts  the  practical  use  of  the  system  to  ground  force  training  while 
ignoring  joint  force  training  with  sea  and  air  components  and  between  crew  members. 

One  solution  to  is  expand  the  capability  of  NPSNET  by  incorporating  a  variety  of 
vehicles  from  different  components  of  the  military  with  the  added  capability  of  multiple 
workstation  control  of  a  single  vehicle.  The  approach  taken  is  to  expand  NPSNET  to 
simulate  helicopter  Anti-Submarine  Warfare.  This  work  focuses  on  realistic  helicopter 
flight  control,  multiple  workstation  control  of  a  single  vehicle,  and  interface  design 
between  workstations  controlling  one  vehicle. 

NPSNET  has  become  a  more  useful  training  tool  for  today’s  military  forces  by 
implementing  more  realistic  helicopter  flight  controls  and  adding  joint  mission  capabilities. 
The  significance  of  this  work  is  that  a  broad  range  of  forces  can  receive  valuable  joint 
training  and  crew  coordination  training  conducted  in  a  virtual  environment. 
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I.  INTRODUCTION 


A.  BACKGROUND 

One  of  the  goals  of  virtual  reality  is  to  present  to  users  an  interactive  environment 
closely  resembling  the  real  world.  While  not  as  real  as  the  world  we  live  in,  we  always 
strive  to  make  it  so,  giving  the  user  of  the  environment  some  sense  that  his  interactions  are 
real.  This  matches  closely  with  a  goal  of  military  computer  simulation:  provide  as  real  a 
training  environment  as  possible  so  as  to  maximize  the  training  benefit  to  the  individual  and 
minimize  the  risks  inherent  in  real  world  training.  With  the  military’s  increasing  emphasis 
on  joint  operations,  conducting  training  exercises  in  real  environments  between  services, 
or  between  different  units  in  the  same  service,  is  vitally  important,  but  logistically  difficult, 
if  not  impossible.  This  is  made  more  difficult  by  the  ever  increasing  demand  for  the  U.S. 
military  to  conduct  extensive  operations  on  unfamiliar  foreign  soil  or  waters  with  little  to 
no  advance  notice. 

NPSNET  is  a  distributed  virtual  environment  and  computer  simulation  research 
effort  which  came  about  in  response  to  these  goals  and  requirements.  By  being  distributed, 
military  units  at  distant  locations  can  interact  with  each  other  in  a  common  and  realistic 
virtual  environment,  providing  useful  training  between  distinct  units  without  the  need  for 
being  in  the  same  physical  location  [ZYDA94].  The  virtual  environment  gives  the  user  the 
feeling  of  being  in  the  real  world  with  the  same  freedom  that  he  would  have  if  he  was  out 
in  the  field.  This  research  is  an  attempt  to  expand  the  scope  of  NPSNET’s  current 
implementation,  which  is  primarily  geared  toward  ground-based  forces  and  operations,  to 
include  naval  helicopter  based  anti-submarine  warfare  (ASW)  forces  and  operations. 
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B.  MOTIVATION 


1.  Expansion  of  NPSNET’s  Scope 

Joint  operations  are  becoming  the  primary  focus  of  the  military.  For  example,  land, 
air,  and  sea  forces  from  the  Army,  Navy,  Air  Force  and  Marine  Corps,  and  armed  services 
from  several  foreign  countries,  were  closely  integrated  in  the  U.S.-Iraqi  War  in  1991. 
Training  and  rehearsal  in  a  virtual  environment  representation  of  the  region  could  be  used 
to  prepare  the  various  components  of  a  joint  military  force  by  giving  them  a  basic  idea  of 
the  terrain  and  what  to  expect  from  other  services  and  units  during  battle.  This  is  not  as 
realistic  as  actually  going  into  the  real  world  environment  of  concern,  but  it  is  a  much  more 
cost  effective  training  tool  than  assembling  all  the  involved  units  at  the  location,  whether 
that  be  land,  sea,  or  air,  or  any  combination  of  these. 

As  already  mentioned,  NPSNET  primarily  simulates  ground-based  military 
operations.  Tanks,  foot  soldiers,  and  helicopter  gunships  represent  the  bulk  of  what  can 
currently  be  simulated.  This  does  not  represent  the  current  trend  in  tactical  training  and 
simulation  described  above.  To  solve  this  problem,  NPSNET  needs  to  be  expanded  to 
involve  more  platform  types  and  more  terrain  databases.  This  would  allow  a  wider  variety 
of  military  units  representing  many  more  operational  platform  types  than  currently 
implemented,  to  benefit  from  the  joint  training  that  NPSNET  can  provide.  Adding 
helicopter  ASW  functionality  to  NPSNET  is  a  step  in  this  direction. 

2.  The  Need  for  a  Realistic  Helicopter  Control  Model 

As  stated  above,  NPSNET  is  a  computer  workstation  based  simulation  program  of 
various  operational  platforms.  To  provide  realistic  simulation  to  users  of  the  system,  the 
user  must  be  able  to  control  the  vehicle  they  are  simulating  in  a  manner  closely 
approximating  the  way  they  would  operate  the  actual  vehicle  they  use.  This  maximizes  the 
training  benefit  of  the  system  by  realistically  simulating  as  many  aspects  of  the  actual 
system  as  practicable,  limited  by  the  capabilities  of  the  workstation  on  which  the  simulation 
will  run  and  the  input  devices  utilized. 
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The  current  implementation  of  helicopter  operations  in  NPSNET  is  based  primarily 
on  tactics.  An  AH-64  helicopter  can  fire  missiles,  shoot  a  machine  gun,  or  drop  bombs. 
With  helicopter  ASW  functionality  added  to  NPSNET,  an  SH-60  helicopter  can  drop 
sonobuoys  or  torpedoes  to  find  a  submarine  or  fire  an  anti-ship  missile.  In  both  of  these 
cases,  however,  only  half  of  what  is  important  to  a  tactical  simulation  is  actually  being 
simulated,  which  happens  to  be  the  tactics  themselves.  Equally  as  important  to  realistic 
simulation  is  actual  control  of  the  vehicle,  in  this  case  the  helicopter. 

The  current  model  of  helicopter  control  in  NPSNET  is  the  same  as  that  for  any  fixed 
wing  aircraft  in  the  system.  While  this  may  provide  enough  realism  and  accuracy  to  the 
simulation  of  a  fixed  wing  aircraft,  it  is  not  at  all  realistic  for  helicopter  control,  which  is 
more  complex.  The  solution  to  this  problem  is  to  change  the  control  paradigm  currently 
used  for  helicopters  to  one  that  more  accurately  reflects  how  a  real  helicopter  is  flown.  This 
provides  a  much  greater  level  of  realism  to  the  user,  thereby  increasing  the  level  of  training 
received. 

C.  OBJECTIVES 

The  objective  of  this  research  is  the  design  and  construction  of  an  interface  to 
simulate  helicopter  ASW  in  NPSNET.  This  interface  provides  to  a  user  on  a  single 
computer  workstation  or  multiple  users  at  different  workstations  representing  one  ASW 
helicopter  the  capability  to  realistically  prosecute  a  subsurface  contact  by  utilizing  the  basic 
ASW  capabilities  added  to  the  system.  The  interface  provides  the  ability  to  exercise  aircrew 
concepts  regardless  of  whether  a  single  workstation  or  multiple  workstations  are 
participating  in  the  simulation.  Another  objective  is  to  increase  the  realism  of  operating  any 
helicopter  in  NPSNET  by  changing  the  control  inputs  to  inputs  representative  of  a  real 
helicopter. 

D.  CHAPTER  SUMMARY 

Chapter  II  provides  an  overview  of  NPSNET,  including  previous  work  forming  the 
basis  of  this  research  effort.  Chapter  HI  describes  some  basics  of  helicopter  control  and 
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crew  concept.  Chapter  IV  provides  an  overview  of  helicopter  based  ASW  operations. 
Chapter  V  details  the  implementation  of  helicopter  control  developed  from  this  research. 
Chapter  VI  describes  the  interface  designed  for  multiple  workstation  helicopter  ASW 
simulation.  Chapter  VII  provides  a  description  of  the  use  of  the  designed  ASW  system. 
Chapter  VIII  details  results  of  testing  of  the  system  and  presents  conclusions  of  this 
research  and  recommendations  for  follow  on  work. 
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II.  PREVIOUS  WORK 


A.  NPSNET  OVERVIEW 

The  Naval  Postgraduate  School  Networked  Vehicle  Simulator  IV  (NPSNET-IV)  is 
a  three-dimensional  virtual  environment  and  visual  simulation  system.  Using  the 
Distributed  Interactive  Simulation  (DIS)  protocol,  it  operates  in  real-time  over  large-scale 

networks  on  commercial,  off-the-shelf  Silicon  Graphics  workstations  [ZYDA95]. 

In  operating  NPSNET-IV,  a  user  on  a  workstation  initializes  the  system  to  simulate 
a  specific  vehicle  in  a  specific  terrain  database.  Currently,  the  user  can  choose  among  a 
number  of  aircraft,  ground  vehicles,  or  a  synthetic  human.  The  choice  of  terrain  database 
includes  a  generic  training  database,  a  database  for  Fort  Hunter  Liggett,  California,  and  a 
database  for  Fort  Benning,  Georgia.  Once  the  system  has  been  initialized,  the  user  has  a 
view  of  the  virtual  environment,  which  is  the  terrain  database  selected,  from  the  vehicle 
chosen.  He  can  then  move  around  in  that  virtual  environment  with  an  amount  of  freedom 
based  on  the  properties  of  the  vehicle  his  workstation  is  simulating  and  can  fire  the  weapons 
that  vehicle  has  been  programmed  to  use. 

When  a  user  chooses  to  initialize  the  workstation  as  a  helicopter,  the  functionality 
provided  is  that  of  a  ground  attack  helicopter,  either  the  AH-64  Apache  or  the  NATO 
designated  HIND  helicopter.  The  weapons  available  include  machine  guns,  missiles  and 
bombs  for  attacking  airborne  or  ground  based  entities.  The  vehicle  is  moved  around  in  the 
virtual  environment  by  “flying”  the  helicopter  with  the  available  input  devices.  These 

devices  include  a  joystick  and  throttle,  keyboard,  or  spaceball  [ZYDA94],  All  of  this  gives 
the  user  the  look  and  feel  of  being  in  his  helicopter  operating  inside  the  virtual  environment. 

What  has  been  described  so  far  only  represents  one  entity  in  the  virtual 
environment:  one  helicopter  in  a  specific  terrain  database.  Another  aspect  of  NPSNET-IV 
that  needs  to  be  described  is  the  network:  how  other  workstations  and  the  vehicles  they 
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simulate  can  interact  with  the  helicopter.  Each  workstation  on  the  network  that  participates 
in  the  simulation  runs  its  own  NPSNET-IV  executable.  When  started,  the  program  searches 
the  local  network  to  see  if  other  workstations  are  participating  in  a  simulation  with  the  same 
exercise  number.  If  so,  these  workstations  now  participate  in  the  same  simulation.  For 
example,  if  the  helicopter  was  initialized  using  the  same  exercise  number  as  another 
workstation,  then  these  two  vehicles  can  interact  with  each  other.  This  interaction  involves 
being  able  to  see  each  other,  fire  weapons  at  each  other,  see  explosions  caused  by  each  other 
and  their  results,  or  team  up  with  each  other  against  other  entities  in  the  simulation. 

All  of  this  interaction  is  possible  through  the  use  of  the  DIS  protocol  over  the 
network.  Each  workstation  transmits  DIS  packets  to  inform  other  workstations  in  the 
simulation  about  the  status  of  that  vehicle.  For  example,  when  the  helicopter  makes  a  turn, 
the  program  sends  a  DIS  packet  onto  the  network  indicating  a  turn.  When  the  other 
workstations  receive  this  packet,  they  update  their  representation  of  that  vehicle  so  that  it 
executes  the  same  turn  as  the  originator.  This  same  scenario  takes  place  for  all  dynamic 
events  in  NPSNET-IV. 

The  DIS  packets  that  are  sent  are  called  protocol  data  units  (PDU’s).  NPSNET-IV 
uses  three  of  the  available  PDU  types  from  the  DIS  protocol.  These  are  the  entity  state 

PDU,  weapon  fire  PDU,  and  detonate  PDU  [ZYDA94].  All  of  these  indicate  to  other 
workstations  in  the  simulation  dynamic  events  that  originate  on  the  sending  workstation. 
The  result  of  this  communication  is  that  each  workstation  conducts  the  same  simulation  so 
that  interaction  among  vehicles  is  as  realistic  as  possible. 

Since  NPSNET-IV  runs  over  a  network,  simulating  a  single  vehicle  is  only  part  of 
what  it  must  do.  Each  workstation  must  also  show  its  user  the  other  vehicles  in  the 
simulation  in  a  realistic  manner.  To  prevent  saturation  of  the  network  with  traffic  to 
constantly  update  the  position  of  each  vehicle  in  the  simulation,  each  workstation  maintains 
a  low  resolution  model  of  the  other  vehicles  in  the  simulation  used  to  calculate  the  predicted 
position  of  those  vehicles  based  on  recent  PDU’s  it  received.  Each  workstation  also 
maintains  two  models  of  itself:  a  high  resolution  model  to  track  its  actual  position  in  the 
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virtual  environment,  and  a  low  resolution  model  which  uses  the  same  prediction  scheme 
noted  above.  This  method  of  prediction  is  called  dead-reckoning,  and  it  keeps  track  of  a 
vehicle’s  position,  attitude,  course  and  speed  by  predicting  from  the  data  contained  in  entity 

state  PDU’s  [ZYDA94],  When  the  two  vehicle  models  a  workstation  maintains  of  itself 
differ  by  a  predetermined  amount  of  error,  or  a  certain  amount  of  time  has  elapsed  since  the 
last  update,  a  new  entity  state  PDU  is  transmitted.  This  causes  the  other  workstations  to 
update  their  low  resolution  model  of  that  vehicle  and  continue  dead-reckoning  from  the 
current  position  stated  in  the  PDU. 

As  noted  earlier,  NPSNET-IV  is  a  real-time  system.  Each  workstation  bases  its 
simulation  on  its  system  clock.  So  regardless  of  the  graphics  frame  rate  that  can  be  achieved 
on  a  particular  workstation,  the  simulation  is  the  same  on  all  workstations.  For  the  dead¬ 
reckoning  procedures  described  above  then,  a  workstation  receives  a  PDU  to  update  some 
other  entity  in  the  simulation.  Since  that  PDU  is  no  longer  current  due  to  network 
transmission  delays,  the  workstation  dead-reckons  from  the  time  listed  in  the  PDU.  This 
time  represents  the  time  that  the  entity  state  PDU  was  generated  and  hence,  when  the 
location  information  about  that  vehicle  was  valid.  The  effect  of  this  dead-reckoning  scheme 
is  that  one  simulation  can  be  conducted  on  a  variety  of  workstations  at  once  without 
sacrificing  accuracy  of  the  simulation.  A  lower-end,  slower  CPU  workstation  can  provide 
just  as  much  realism  in  the  simulation  as  one  executed  on  a  higher-end,  fast  CPU  and 
multiple  CPU  workstation.  All  workstations  show  the  same  vehicles  behaving  alike  and 
place  them  in  accurate  locations  since  it  is  all  based  on  time. 

The  final  part  of  the  simulation  that  must  be  dealt  with  is  the  terrain.  In  NPSNET- 
IV,  each  workstation  maintains  its  own  copy  of  the  terrain  database.  This  allows  for  a  high 
amount  of  detail  when  each  workstation  draws  the  terrain  while  at  the  same  time  preventing 
large  amounts  of  network  traffic  that  would  be  needed  if  the  database  were  stored  in  a 
central  location. 
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B.  NPSNET  PANEL  INTERFACE 


In  thesis  work  by  Chris  McMahan,  a  windowed  subsystem  of  NPSNET  was 
developed  to  provide  a  common  interface  for  the  various  vehicles  of  a  simulation 
[MCMA95].  This  interface  was  constructed  using  Motif  and  the  Viewkit  Development 
Toolkit  to  separate  the  functionality  of  the  interface  from  the  simulation  and  visualization 
engines.  The  advantage  of  this  approach  is  that  it  allows  development  of  new  interface 
components  without  sacrificing  speed  or  efficiency  in  NPSNET.  It  also  allows  users  to 
easily  adapt  to  methods  of  controlling  different  types  of  vehicles  without  having  to 
memorize  the  many  keyboard  commands  now  used  to  control  vehicles. 

There  are  some  disadvantages  to  this  approach.  First,  use  of  this  interface  panel 
detracts  from  the  realism  of  a  simulation.  When  used  as  the  primary  interface  for  a  vehicle 
in  a  simulation,  a  mouse  adjusts  the  various  components  of  the  panel,  which,  in  turn, 
controls  the  vehicle.  Real  vehicles  use  real  controls.  To  simulate  these  vehicles  realistically, 
similar  controls  are  needed  to  provide  the  user  with  the  feel  of  the  vehicle  he  is  simulating. 
If  the  panel  is  used  as  secondary  instrumentation  for  a  vehicle,  however,  realism  can  be 
maintained  while  still  providing  more  information  to  the  user. 

Another  disadvantage  of  the  interface  employed  in  McMahan’s  research  is  that 
there  is  no  concept  of  one  panel  controlling  one  vehicle  while  another  panel  controls 
another  vehicle.  The  reason  for  this  is  that  the  communication  between  the  panel 
application  and  NPSNET  has  no  facility  for  identifying  which  packet  goes  to  which  entity 
of  the  simulation.  In  addition,  when  NPSNET  sends  packets  to  the  panel,  there  is  no 
identifying  information  about  which  entity  sent  the  packet.  The  result  of  this  is  that  the 
panel  shows  information  from  all  entities  in  the  simulation,  and  any  controlling  information 
sent  by  the  panel  to  the  entity  goes  to  any  entity  that  has  remote  control  designated  at 
initialization.  Only  one  panel  can  effectively  be  used  with  one  entity,  while  the  rest  of  the 
entities  have  no  panel  associated  with  them  in  the  simulation. 

Despite  these  drawbacks,  the  interface  panel  concept  developed  by  McMahan  is 
useful  to  this  research  as  mentioned  above:  as  secondary  instrumentation  to  users  of  the 
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ASW  helicopter  being  developed.  If  the  panel  can  be  instantiated  once  for  every  ASW 
helicopter  initialized,  the  door  is  open  for  two  users  to  control  the  helicopter,  one  using  the 
flight  controls  and  visualization  effects  already  provided  by  NPSNET,  and  the  other 
controlling  the  ASW  tactical  situation  from  information  provided  by  the  interface  panel.  If 
the  two  users  operating  these  functions  can  communicate  through  their  respective 
interfaces,  a  realistic  simulation  can  be  conducted  which  provides  a  degree  of  crew  concept 
needed  to  effectively  prosecute  a  subsurface  contact. 
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III.  BASICS  OF  HELICOPTER  FLIGHT 


A.  INTRODUCTION 

To  understand  what  is  needed  to  make  simulation  of  helicopters  more  realistic  in 
NPSNET,  on  must  first  understand  how  a  real  helicopter  operates.  This  chapter  describes 
basic  helicopter  aerodynamics,  helicopter  flight  control,  and  the  major  components  of  a 
helicopter.  While  not  intended  to  be  a  comprehensive  examination  of  helicopter  flight,  the 
information  contained  here  is  provided  as  background  for  the  changes  made  to  NPSNET 
helicopter  simulation,  as  described  in  Chapter  V. 

B.  HELICOPTER  AERODYNAMICS 

There  are  several  techniques  for  describing  the  physics  of  flying  helicopters.  The 
most  realistic  method  used  today  is  “blade  element  theory”,  which  describes  the 
aerodynamic  elements  of  flight  by  dealing  with  the  forces  on  each  individual  rotor  blade 

[PROU86].  This  method  for  calculating  helicopter  motion  is  used  in  modem  flight 
simulators  since  it  can  provide  a  great  deal  of  realism  to  the  pilot  in  the  simulation.  While 
very  complex,  these  types  of  simulators  accomplish  real  time  calculation  and  simulation 
through  the  use  of  specialized  computing  hardware.  The  design  of  these  computer  systems 
is  specifically  aimed  at  fast  performance  of  complex  integration  to  provide  the  most  realism 
possible  to  pilots. 

The  blade  element  method  quickly  becomes  impractical  when  considering 
NPSNET,  which  must  calculate  motion  for  a  variety  of  vehicle  types  using  off-the-shelf 
computer  systems  over  a  networked  environment.  The  comparative  slowdowns  caused  by 
the  use  of  these  systems  make  the  realism  provided  by  the  blade  element  method  impossible 
to  recreate.  In  addition,  NPSNET  was  not  designed  to  provide  this  level  of  detail  to  the 
individual  user. 
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A  simpler  method  is  the  “balance  of  forces”  method.  This  method  describes  motion 
resulting  from  the  forces  acting  on  an  airframe.  The  major  forces  acting  on  a  helicoter 
airframe  are  lift,  thrust,  drag,  weight  and  torque.  Representing  these  forces  by  vectors  gives 
a  much  less  complex  description  of  aerodynamics  in  a  helicopter,  allowing  faster 
computation  and  a  more  realistic  simulation  than  is  currently  accomplished  in  NPSNET. 

Figure  1  shows  a  general  description  of  the  balance  of  forces  on  a  generic  airframe. 
Assuming  in  this  general  case  that  lift,  weight,  thrust  and  drag  all  act  on  the  aircraft’s  center 
of  gravity  (C.G.),  steady  state  flight  can  be  maintained  if  all  of  these  forces  cancel  each 
other  out.  Steady  state  flight  is  when  there  is  no  acceleration  or  deceleration,  or  constant 
altitude  and  constant  velocity.  In  the  diagram,  if  the  lift  vector  is  equal  in  length  to  the 
weight  vector  and  in  the  exact  opposite  direction,  the  aircraft  will  not  accelerate  up  or 
down.  The  same  is  true  of  thrust  and  drag:  if  they  are  equal  in  length  but  opposite  in 
direction,  the  aircraft  will  not  accelerate  or  decelerate  in  its  forward  motion.  If  both  of  these 
cases  exist  at  once,  the  aircraft  will  be  in  steady  state  flight. 
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Figure  1:  Generic  Balance  of  Forces 


In  a  helicopter,  Figure  1  changes  slightly.  Figure  2  shows  how  the  same  forces  are 
represented  in  a  helicopter.  The  main  difference  is  that  lift  and  thrust  emanate  from  the 
center  of  the  rotor  on  top  of  the  aircraft,  while  weight  and  drag  still  originate  at  the  C.G. 
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Figure  2:  Helicopter  Balance  of  Forces 


The  following  sections  give  descriptions  of  each  force  as  they  apply  to  the  balance  of  forces 
method  for  describing  the  aerodynamics  of  helicopter  flight. 

1.  Weight 

The  simplest  of  the  forces  in  Figure  2  is  weight.  Weight  is  a  force  that  originates  at 
the  C.G.  of  the  helicopter  and  points  to  the  ground.  Weight  comes  from  the  following 
equation: 

F  =  mx  a  (Eq.  1) 

where: 

F  =  weight,  the  weight  of  the  helicopter, 
m  =  mass  of  the  helicopter,  and 
a  =  acceleration,  the  acceleration  of  gravity. 

To  overcome  the  weight  of  the  helicopter  and  produce  flight,  the  main  rotor  of  the 
helicopter  produces  lift.  When  the  amount  of  lift  is  greater  than  the  weight,  the  helicopter 
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will  climb.  Conversely,  when  the  lift  is  less  than  the  weight,  the  helicopter  descends.  And 
when  the  two  are  equal,  altitude  is  maintained. 

In  helicopter  flight,  weight  changes  as  fuel  is  used  during  a  flight.  As  more  fuel  is 
burned,  the  helicopter  becomes  lighter.  This  results  in  less  power  required  to  maintain 
steady  state  flight  since  the  amount  of  lift  needed  to  offset  weight  becomes  less. 

2.  Lift 

The  easiest  way  to  describe  lift  is  by  describing  how  a  helicopter  hovers.  In  a 
helicopter,  lift  is  produced  directly  by  the  main  rotor.  As  power  is  applied  by  the  pilot,  more 
lift  is  created.  When  the  amount  of  lift  becomes  greater  than  the  weight  of  the  helicopter  as 
described  above,  the  helicopter  will  climb. 

The  reason  this  occurs  is  that  each  blade  of  the  main  rotor  is  an  airfoil,  just  like  the 
wings  of  a  fixed-wing  aircraft.  With  no  power  applied,  the  pitch  of  each  blade  is  effectively 
zero,  so  no  lift  is  produced  by  the  main  rotor  blades.  As  the  pilot  applies  power,  the  pitch 
of  all  the  blades  increases,  so  lift  is  produced.  If  enough  power  is  applied,  the  rotor  blades 
will  produce  enough  lift  to  equal  the  weight,  and  a  hover  is  produced.  For  example,  if  a 
helicopter  weighs  20,000  pounds,  the  amount  of  lift  required  to  hover  is  20,000  pounds.  If 
less  than  20,000  pounds  of  lift  is  produced,  the  helicopter  descends.  If  there  is  more  than 
20,000  pounds  of  lift,  it  climbs. 

Lift  is  represented  by  a  vector  originating  from  the  center  of  the  main  rotor.  It  is 
perpendicular  to  the  plane  of  the  main  rotor  blades  and  points  up. 

3-  Thrust 

Helicopters  do  not  produce  thrust  like  a  fixed  wing  aircraft.  Jets  and  propeller 
airplanes  produce  thrust  by  driving  a  large  volume  of  air  rearward  while  the  stationary 
wings  produce  lift  due  to  volumes  of  air  flowing  over  them.  In  a  helicopter,  lift  is  produced 
when  the  main  rotor  blades  move  through  the  air  fast  enough  to  obtain  sufficient  airflow 
over  them  then  drive  the  airflow  downward  by  pitching  the  blades  up.  Thrust,  however. 
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must  be  indirectly  produced.  The  way  it  is  accomplished  is  by  tilting  the  main  rotor  from 
the  horizontal  plane.  This  is  shown  in  Figure  3. 
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a)  Forward  10  degrees  pitch 

b)  Forward  30  degrees  pitch 

Figure  3:  Lift  vs.  Thrust 


As  can  be  seen  in  Figure  3,  the  total  lift  between  the  two  helicopters  is  the  same,  as 
are  their  weights.  The  helicopter  on  the  left  has  less  pitch,  so  the  effective  lift,  the  vertical 
component  of  total  lift,  is  only  slightly  less  than  if  there  was  zero  pitch.  The  horizontal 
component,  effective  thrust,  has  appeared  as  well.  This  helicopter  will  start  to  accelerate 
forward  from  the  amount  of  effective  thrust,  but  will  start  to  descend  slightly  as  the 
effective  lift  decreases  enough  to  be  unable  to  counteract  weight. 

The  helicopter  on  the  right  in  Figure  3  has  significantly  more  forward  pitch  than  the 
helicopter  on  the  left.  The  effect  here  is  that  there  is  significantly  more  effective  thrust  and 
less  effective  lift.  The  helicopter  will  accelerate  faster  and  descend  more  quickly. 

One  of  the  unique  features  of  the  helicopter  is  that  thrust  can  be  produced  in  any 
direction  by  tilting  the  main  rotor  in  that  direction,  including  backwards  and  sideways.  This 

is  shown  in  Figure  4.  The  importance  of  this  unique  quality  can  be  seen  in  the  helicopter’s 
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ability  to  hover.  By  tilting  the  main  rotor  in  the  desired  direction,  the  helicopter  can  be  made 
to  fly  sideways  or  even  backwards. 


a)  Backward  20  degrees  pitch 
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Figure  4:  Backwards  and  Sideways  Thrust 


4.  Drag 

As  shown  in  Figure  2,  drag  is  the  force  that  thrust  must  counteract  to  provide 
acceleration  and  constant  state  velocity.  Drag  is  opposite  to  the  direction  of  motion.  The 
amount  of  drag  is  dependent  on  the  magnitude  and  direction  of  the  helicopter’s  velocity  and 
the  angle  of  attack  of  the  helicopter’s  fuselage  to  the  oncoming  airflow.  As  velocity 
increases,  drag  on  the  fuselage  increases,  resulting  in  the  need  for  more  power  to  go  faster. 
In  a  similar  manner,  drag  is  at  a  minimum  when  the  fuselage  is  heading  forward.  When 
flying  sideways,  the  cross-sectional  area  of  the  fuselage  into  the  airstream  is  much  larger, 
resulting  in  higher  drag.  Therefore,  it  takes  less  power  to  fly  forward  than  it  does  to  fly 
sideways  at  the  same  speed. 
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5.  Torque 

Another  major  force  produced  by  a  helicopter  is  torque,  as  illustrated  in  Figure  5. 
The  engines  drive  a  transmission  which  spins  the  main  rotor  in  a  counterclockwise 
direction.  This  spinning  causes  the  fuselage  to  try  to  rotate  in  the  opposite  direction, 
clockwise.  If  this  torque  force  isn’t  counteracted,  the  helicopter  would  spin  out  of  control. 


There  are  several  ways  modern  helicopters  counteract  this  torque  force.  The  most 
common  way  is  through  the  use  of  a  tail  rotor.  This  anti-torque  device  is  mounted  on  the 
tail  of  the  helicopter  and  is  oriented  parallel,  or  nearly  parallel,  to  the  fuselage,  as  in  Figure 
5.  The  tail  rotor  produces  thrust  counterclockwise  which  pulls  the  tail  end  of  the  fuselage 
preventing  the  spinning.  So  it  provides  directional  control  for  the  fuselage,  both  in  a  hover 
and  in  forward  flight. 

Another  way  that  main  rotor  torque  is  counteracted  is  to  have  two  main  rotors 
spinning  in  opposite  directions.  Since  they  spin  in  opposite  directions,  the  torque  that  each 
produces  is  counteracted  by  the  other,  resulting  in  no  torque  on  the  fuselage.  A  newer 
method  of  counteracting  torque  is  the  NOTAR  system,  where  a  jet  engine  serves  the  same 
function  as  the  tail  rotor.  Located  in  approximately  the  same  position  as  a  tail  rotor,  it 
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produces  anti-torque  by  pushing  air  away  from  the  direction  of  rotation  desired  for  the 
fuselage.  This  pushes  the  fuselage  in  the  correct  direction  to  maintain  directional  control. 

C.  HELICOPTER  CONTROL 

Now  that  all  of  the  aerodynamic  forces  have  been  explored,  how  are  these 
controlled  to  actually  fly  a  helicopter?  This  section  describes  the  common  controls  used  by 
most  helicopters:  the  collective,  the  cyclic  and  the  rudder  pedals.  These  control  devices  are 

shown  in  Figure  6. 


Figure  6:  Helicopter  Control  Components 
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1. 


Collective 


The  collective  controls  the  pitch  of  the  main  rotor  blades.  Controlled  by  the  left 
hand,  the  collective  is  moved  up  and  down  to  increase  or  decrease  the  pitch  of  the  blades 
all  the  same  amount,  or  collectively.  This  increase  in  pitch  increases  the  lift  produced  by 
the  main  rotor  and  gives  the  helicopter  the  ability  to  climb.  Similarly,  moving  the  collective 
down  decreases  the  pitch  on  the  main  rotor  blades  producing  less  or  no  lift,  resulting  in  a 
descent. 


2.  Cyclic 

The  cyclic  provides  the  pitch  and  roll  control  of  the  helicopter.  By  moving  the 
cyclic  to  the  left  or  right,  the  pitch  on  each  of  the  main  rotor  blades  is  adjusted  so  that  the 
main  rotor  disc  tilts  the  same  respective  direction.  Tilting  the  main  rotor  in  this  fashion  rolls 
the  fuselage  and  results  in  a  turn  or  a  slide. 

Pitch  is  controlled  in  the  same  way  as  roll.  If  the  pilot  wishes  to  pitch  the  nose  of 
the  helicopter  down,  he  pushes  forward  on  the  cyclic.  This  causes  the  main  rotor  blades  to 
change  pitch  in  cycle,  driving  the  nose  of  the  helicopter  down  and  accelerating  the 
helicopter. 

Pitch  and  roll  commands  through  the  cyclic  can  be  combined  as  well.  For  example, 
forward  pitch  and  left  roll  can  be  commanded  for  by  moving  the  cyclic  to  the  forward  left 
position  from  its  center.  Any  combination  of  pitch  and  roll  can  be  input,  which  tilts  the  main 
rotor  in  the  desired  direction  producing  acceleration  in  that  direction. 

3.  Rudder  Pedals 

The  rudder  pedals  provide  directional  control  by  changing  the  pitch  on  the  tail  rotor, 
changing  the  amount  of  anti-torque  as  described  earlier.  Generally,  with  the  rudder  pedals 
in  the  center  position,  enough  anti-torque  is  produced  for  the  fuselage  to  maintain  constant 
heading.  Pushing  the  left  pedal  forward  increases  the  amount  of  anti-torque,  turning  the 
fuselage  to  the  left.  Pushing  right  pedal  turns  the  helicopter  to  the  right  by  decreasing  anti¬ 
torque. 
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4.  Combining  Controls 

In  any  aircraft,  changing  control  to  produce  one  desired  effect  usually  requires  at 
least  one  other  control  movement  to  maintain  steady  flight.  One  example  would  be  using 
the  collective  to  start  a  climb.  When  the  collective  is  raised,  the  pitch  of  the  main  rotor 
blades  increases  to  produce  more  lift.  A  climb  results.  One  side  effect  of  increasing  the 
collective  is  a  corresponding  increase  in  torque.  This  is  because  the  pitch  of  all  the  main 
rotor  blades  increase  and  more  power  is  required  to  keep  them  turning  at  a  constant  rate. 
This  results  in  more  torque  on  the  fuselage,  so  it  begins  to  spin  slowly  to  the  right.  To 
counteract  this,  increases  in  collective  are  usually  accompanied  by  adding  left  pedal.  This 
helps  the  helicopter  maintain  a  constant  heading. 

Another  example  is  the  relationship  between  cyclic  pitch  and  collective.  If  the  pilot 
wishes  to  accelerate  forward  but  maintain  his  current  altitude,  he  must  push  the  cyclic 
forward  to  tilt  the  main  rotor  forward.  As  described  earlier,  this  increases  the  effective 
thrust  produced  by  the  main  rotor  and  decreases  the  effective  lift.  To  maintain  the  current 
altitude,  the  pilot  must  then  increase  the  amount  of  effective  lift  by  raising  the  collective. 
Finally,  the  situation  described  above  occurs  due  to  the  collective  being  increased,  so  left 
pedal  must  also  be  applied  to  maintain  heading. 

5.  Engine  Control 

Another  concept  that  should  be  explained  is  the  role  the  engines  play  in  helicopter 
flight.  In  jet  aircraft,  the  amount  of  thrust  is  directly  related  to  the  speed  of  the  engines.  If 
the  pilot  wishes  to  go  faster,  he  increases  the  throttle  to  speed  up  the  engines,  which 
produces  more  thrust. 

In  a  helicopter,  however,  more  lift  is  produced  by  increasing  the  pitch  on  the  main 
rotor  blades.  As  was  stated  earlier,  the  main  rotor  blades  spin  at  a  generally  constant  rate. 
The  engines  drive  a  shaft  which  drives  a  large  reduction  gear  transmission.  This 
transmission  spins  the  main  rotor  and  the  tail  rotor.  Since  it  is  desired  that  the  main  rotor 
spins  at  a  constant  rate,  the  engines  run  at  a  constant  speed.  Controlling  the  pitch  of  the 
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rotors  is  accomplished  through  direct  linkages  to  the  cyclic,  collective,  and  rudder  pedals. 
The  only  times  that  the  speed  of  the  engines  deviates  from  their  desired  constant  speed  is 
during  start-up,  shutdown,  and  engine  malfunction.  In  normal  flight  regimes,  engine  speed 
is  not  adjusted,  so  it  is  unrelated  to  control  of  lift  and  thrust. 

6.  Maximum  Forward  Airspeed  in  Level  Flight 

This  is  another  important  concept  in  helicopter  flight.  There  are  two  limits  related 
to  this  concept:  an  aerodynamic  limit  and  a  control  limit. 

The  aerodynamic  limit  is  related  to  the  spinning  of  the  main  rotor  blades  and  is 
called  blade  stall.  Blade  stall  is  defined  to  be  the  tendency  of  the  retreating  blade  to  stall  in 

forward  flight  [NTPS90].  Figure  7  shows  the  difference  between  the  speeds  of  the  main 
rotor  blades  relative  to  the  oncoming  airflow.  The  airspeed  of  a  rotor  blade  is  calculated  by 
adding  the  rotational  speed  of  the  rotor  blade  to  the  forward  airspeed  of  the  helicopter. 

When  the  helicopter  is  in  a  hover,  as  in  Figure  7a,  forward  airspeed  of  the  helicopter  is  zero. 
Therefore,  airspeeds  of  the  advancing  and  retreating  blades  are  the  same.  In  fact,  the 
airspeed  of  any  blade  throughout  the  360  degrees  of  rotation  is  the  same. 

In  forward  flight,  however,  the  advancing  blade  is  rotating  into  the  oncoming 
airflow  while  the  retreating  blade  is  rotating  away  from  it.  Figure  7b  shows  that  the 
advancing  blade  has  a  much  faster  airspeed  than  the  retreating  blade.  The  airspeed  of  the 
retreating  blade  is  calculated  by  subtracting  the  forward  airspeed  of  the  helicopter  from  the 
rotational  velocity  of  the  blade  since  it  is  opposite  in  direction  to  the  oncoming  airflow.  The 
result  is  that  the  retreating  blade  must  increase  pitch  to  maintain  the  same  amount  of  lift  as 
the  advancing  blade.  If  the  forward  airspeed  is  too  high,  the  increase  in  pitch  of  the 
retreating  blade  will  cause  it  to  stall,  or  lose  its  ability  to  produce  lift.  The  advancing  blade 
will  produce  a  high  amount  of  lift,  even  at  low  blade  pitch  angles,  since  its  airspeed  is  so 
great.  Since  one  side  of  the  aircraft  has  lift  and  the  other  side  does  not,  such  an  airspeed  will 
cause  the  helicopter  to  depart  from  controlled  flight.  Due  to  the  fact  that  the  effect  of  each 
main  rotor  blade  on  the  total  lift  is  manifested  90  degrees  later,  the  helicopter  nose  will 
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pitch  up  when  the  retreating  blade  stalls.  This  has  the  effect  of  decreasing  forward  airspeed 
thus  increasing  the  relative  airspeed  of  the  retreating  blade.  Thus,  the  stall  condition  is 
automatically  corrected.  However,  the  forces  on  the  main  rotor  system  during  this 
transition  from  normal  flight  to  stall  and  back  can  result  in  catastrophic  damage.  Hence, 
helicopter  flight  manuals  limit  the  forward  airspeeds  that  a  pilot  is  allowed  to  fly  so  that  this 

blade  stall  condition  is  avoided.  [NTPS90] 


The  other  limitation  on  forward  airspeed  is  a  result  of  control  limits.  As  forward 
airspeed  increases,  the  pilot  must  increase  collective  to  maintain  altitude,  as  described 
earlier.  If  the  helicopter  is  heavy  enough,  the  collective  will  reach  the  upper  limit  of  its 
control  range  before  blade  stall  airspeed  is  reached.  In  this  case,  maximum  forward 
airspeed  in  level  flight  is  limited  by  the  physical  control  movement  limit  instead  of  the 
aerodynamic  limit  of  blade  stall. 
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D.  HELICOPTER  COMPONENTS 

All  modem  powered  aircraft  are  made  up  of  components  necessary  to  stay  airborne 
in  level  flight.  These  consist  of  the  fuselage,  engines,  some  type  of  airfoils,  and  the  cockpit. 
These  components  are  present  in  fixed-wing  aircraft  and  helicopters,  but  their  structure  and 

function  can  differ.  Figure  8  shows  these  components  on  a  helicopter. 


airfoil  (main  rotor)  engines  airfoil  (tail  rotor) 


cockpit  launcher  fuselage 


Figure  8:  Helicopter  Components 

The  purpose  of  a  fuselage  is  the  same  for  a  helicopter  and  fixed-wing  airplane:  to 
house  crewmembers  and  cargo,  and  to  serve  as  an  attachment  point  for  the  external 
components  of  the  aircraft.  In  a  helicopter,  the  engines,  rotors,  and  transmissions  are  all 
attached  to  the  fuselage.  In  addition,  all  electrical  components  and  control  linkages  are 
inside  the  fuselage. 

The  next  major  component  of  a  helicopter  is  the  engine.  This  is  usually  a  gas- 
turbine,  or  “jet”  engine,  and  many  helicopters  have  two  or  more  engines.  The  purpose  of 
the  engines  is  to  drive  the  thrust  producing  component  of  aircraft.  In  a  jet  airplane,  the  thrust 
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producer  are  turbines  internal  to  the  engine,  and  in  a  propeller  airplane,  it  is  the  propeller. 
In  a  helicopter,  this  is  the  rotor  system. 

The  rotor  system  is  a  component  that  is  unique  to  helicopters.  Most  helicopters  have 
a  rotor  system  composed  of  a  main  rotor  and  a  tail  rotor.  The  main  rotor  is  a  series  of  large 
blades  that  spin  to  produce  both  lift  and  thrust.  When  the  pitch  on  the  blades  is  increased, 
the  blades  produce  more  lift.  When  the  blades  are  tilted,  thrust  is  produced  in  the  direction 
of  the  tilt. 

The  tail  rotor  is  the  anti-torque  device  on  a  helicopter.  By  pulling/pushing  the  tail 
of  the  fuselage  opposite  the  direction  resulting  from  the  torque  produced  by  the  main  rotor 
blades,  directional  control  of  the  helicopter  is  achieved. 

Finally,  the  cockpit  is  the  location  where  the  pilots  sit  to  control  the  aircraft.  An 

example  of  a  cockpit  is  shown  in  Figure  6.  The  cyclic,  collective,  and  rudder  pedals  are 
located  in  the  cockpit,  with  duplicate  sets  for  the  pilot  and  copilot.  Both  the  pilot  and  copilot 
have  full  control  capability  over  the  helicopter.  In  addition  to  the  flight  controls,  other 
components  located  in  the  cockpit  are  flight  and  engine  instruments,  electrical  controls  and 
circuit  breakers,  and  tactical  controls.  The  cockpit  contains  ample  windows  for  the  pilots  to 
see  forward,  up,  down,  and  to  the  side.  This  allows  them  to  fly  in  any  direction  and  land  in 
any  suitable  location. 

E.  SUMMARY 

Although  many  of  the  key  concepts  of  helicopter  aerodynamics  and  flight  have 
been  introduced  here,  much  of  the  detail  has  been  left  out.  Only  basic  concepts  were 
addressed  in  the  context  of  NPSNET,  so  only  those  concepts  were  explained  in  any  detail. 
More  complex  concepts,  like  extreme  aerodynamic  situations,  emergency  procedures,  and 
autorotations,  were  not  introduced  as  they  are  beyond  the  scope  of  this  research. 
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IV.  BASICS  OF  HELICOPTER  ASW 


A.  INTRODUCTION 

The  other  portion  of  this  research  involves  simulating  a  helicopter  conducting  an 
anti-submarine  warfare  (ASW)  mission.  To  understand  the  simulation  system  that  is 
implemented,  this  chapter  describes  the  components  of  an  ASW  mission:  the  flightcrew, 
the  sensors,  and  the  weapons.  The  descriptions  given  are  specific  to  the  SH-60B  helicopter, 
but  generally  apply  to  most  modem  ASW  helicopters. 

B.  HELICOPTER  ASW  FLIGHTCREW 

The  flightcrew  of  an  ASW  mission  in  an  SH-60B  helicopter  consists  of  three 
members:  the  pilot,  the  Airborne  Tactical  Officer,  and  the  Sensor  Operator.  Each  has 
specific  responsibilities  in  an  ASW  mission. 

1.  Pilot 

The  pilot  performs  the  flight  maneuvers  of  a  mission.  His  primary  responsibility  is 
the  safe  conduct  of  the  mission,  and  he  must  coordinate  the  tactics  used  during  the  flight 

with  the  ATO.  [LWSM92] 

2.  Airborne  Tactical  Officer  (ATO) 

The  primary  responsibility  of  the  ATO  is  the  tactical  conduct  of  the  ASW  mission. 
This  includes  deciding  where  to  deploy  sonobuoys,  maintaining  tracks  on  submarine 
contacts,  managing  use  of  all  helicopter  sensors,  navigation  to  target  areas  for  employment 
of  sensors  and  weapons,  directing  weapon  delivery  and  evaluation  of  attacks.  Another 
important  responsibility  is  to  back  up  the  pilot  in  safe  conduct  of  the  mission.  [LWSM92] 
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3.  Sensor  Operator  (SO) 

The  SO’s  primary  responsibility  is  to  operate  the  aircraft’s  sensors  and  monitor  the 
status  of  the  system.  He  controls  the  radar/IFF  system,  analyzes  data  from  any  sonobuoys, 

controls  the  MAD  system  and  analyzes  its  data.  [LWSM92] 

4.  Aircrew  Coordination 

One  of  the  most  important  aspects  of  safe  and  successful  completion  of  an  ASW 
mission  is  aircrew  coordination.  The  concept  is  based  on  each  member  of  the  flightcrew 
taking  care  of  his  own  responsibilities  during  the  mission  while  supporting  the  other 
members  of  the  flightcrew  in  their  responsibilities. 

Crew  coordination  works  like  this:  the  pilot  operates  the  flight  controls  as  his 
primary  duty.  He  also  helps  the  ATO  in  his  duties  by  keeping  the  helicopter  at  an  optimum 
altitude  and  location  to  accomplish  the  next  task  of  the  mission.  This  is  so  sonobuoys  or 
torpedoes  can  be  launched  quickly  when  needed.  The  pilot  also  maintains  a  lookout  for 
possible  visual  contact  with  a  submarine,  either  by  seeing  one  underwater  or  by  seeing  its 
periscope. 

The  ATO  controls  the  conduct  of  the  tactical  portion  of  the  mission.  For  his  part  of 
crew  coordination,  he  backs  up  the  pilot  on  the  flight  instruments  so  that  safety  of  flight  is 
maintained.  If  the  pilot  flies  the  helicopter  into  an  unsafe  situation,  the  ATO  is  responsible 
for  notifying  the  pilot  or  taking  the  control  of  the  helicopter  to  get  it  back  in  a  safe  flight 
regime. 

In  addition  to  operating  the  helicopter’s  sensors,  the  SO  aids  the  ATO  by  giving 
advice  about  the  deployment  of  sonobuoys  and  weapons  based  on  the  information  being 
received  by  the  sensors.  He  also  informs  the  pilot  and  ATO  of  equipment  malfunctions  or 
failures  that  affect  the  mission  or  the  safety  of  flight. 
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C.  HELICOPTER  ASW  SENSORS 

The  SH-60B  helicopter  sensors  for  use  in  ASW  missions  are  sonobuoys,  the  radar/ 
Identification  Friend  or  Foe  system,  and  the  magnetic  anomaly  detector  system.  This 
section  gives  a  brief  description  of  each  of  these. 

1.  Sonobuoys 

The  primary  ASW  sensor  for  the  SH-60B  is  the  sonobuoy.  A  sonobuoy  is  an 
acoustic  underwater  sensor  used  for  detecting  submarines.  The  sonobuoy  is  a  cylinder 
about  forty  inches  long  and  eight  inches  in  diameter.  When  launched  from  the  helicopter 
in-flight,  it  falls  until  it  hits  the  water,  at  which  point  the  cylinder  deploys  a  float  to  stay  on 
the  surface  of  the  water.  This  float  contains  a  radio  transmitter  for  transmitting  information 
back  to  the  helicopter.  The  sonobuoy  also  deploys  an  underwater  microphone,  called  a 
hydrophone,  several  hundred  feet  below  it  to  listen  for  acoustic  signals. 

There  are  two  kinds  of  sonobuoys  used  by  the  SH-60B  helicopter:  active  sonobuoys 
and  passive  sonobuoys.  The  passive  sonobuoy  can  only  receive  acoustic  signals,  as  shown 

in  Figure  9.  Any  acoustic  data  received  by  the  hydrophone  is  transmitted  back  to  the 
helicopter  via  the  radio  transmitter.  Computers  in  the  helicopter  analyze  the  signals  and 
transform  them  into  usable  information  for  the  aircrew.  The  information  tells  the  aircrew 

the  bearing  from  the  sonobuoy  to  the  subsurface  contact.  [LWSM92] 

An  active  sonobuoy  transmits  a  sonar  signal  from  its  hydrophone  into  the  water, 
then  listens  for  the  echo  of  that  signal.  The  echo  of  the  sonar  signal  is  received  when  it  is 
reflected  off  of  an  underwater  contact  back  to  the  hydrophone  as  in  Figure  10.  The  data  is 
transmitted  back  to  the  helicopter  via  the  radio  transmitter  and,  when  analyzed,  gives  range 

and  bearing  information  from  the  sonobuoy  to  the  submarine.  [LWSM92] 

The  SH-60B  helicopter  can  carry  and  launch  any  combination  of  up  to  25  active  or 
passive  sonobuoys.  The  sonobuoy  launcher  is  located  on  the  left  side  of  the  fuselage,  as 

seen  in  Figure  8.  [LWSM92] 
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Figure  9:  Passive  Sonobuoy  Operation 


2.  Radar  and  Identification  Friend  or  Foe  (IFF)  System 

The  radar  system  is  used  to  detect  surface  or  airborne  contacts  [LWSM92].  In  the 
ASW  mission,  the  radar  is  used  to  detect  surfaced  submarines  or  enemy  ships. 

The  IFF  system  is  located  on  the  radar  and  is  used  to  identify  whether  potential 

threats  are  from  enemy  forces  or  friendly  forces  [LWSM92].  The  system,  like  the  radar, 
does  not  have  underwater  capability,  so  its  use  in  ASW  is  limited  to  identification  of 
airborne  and  surfaced  contacts,  including  surfaced  submarines. 

3.  Magnetic  Anomaly  Detector  (MAD) 

The  MAD  system  is  designed  to  detect  submarines  by  measuring  the  earth’s 
magnetic  field.  It  accomplishes  this  by  detecting  disturbances  in  the  earth’s  magnetic  field 
caused  by  a  submarine.  The  system  then  gives  the  aircrew  a  location  at  which  the 

disturbance  occurred.  [LWSM92] 
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D.  HELICOPTER  ASW  WEAPONS 

1.  Mk  46  and  Mk  50  Torpedoes 

The  torpedo  is  the  primary  ASW  weapon  used  by  the  SH-60B  helicopter.  The 
torpedo  is  launched  from  pylons  on  either  side  of  the  helicopter  fuselage.  When  launched, 
the  torpedo  falls  unguided  to  the  water.  After  water  impact,  it  uses  active  sonar  to  home  in 
on  subsurface  contacts.  The  launch  point  of  the  torpedo  is  determined  by  the  ATO  based 
on  his  track  of  the  submarine  and  the  capabilities  of  the  torpedo  that  will  be  launched. 

[LWSM92] 

Details  about  search  patterns,  acquisition  ranges,  run  times  and  speeds  of  either  the 
Mk  46  or  Mk  50  torpedo  are  classified  and  beyond  the  scope  of  this  research.  The 
description  given  above  is  general  and  the  extent  of  what  will  be  simulated  as  a  result  of 
this  research. 
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2.  Penguin  Missile 

The  only  other  ASW  weapon  capable  of  being  carried  on  the  SH-60B  is  the  Penguin 
missile.  This  is  an  infrared  homing,  air-to-surface  missile.  Launched  from  pylons  on  the 
fuselage,  the  missile  is  a  “fire  and  forget”  weapon,  meaning  that  once  it  is  fired,  it  is  not 
dependent  on  the  helicopter  for  any  information  or  guidance.  Prior  to  launch,  though,  the 
missile  receives  aircraft  velocity,  heading  and  altitude  information  and  targeting 
information  from  the  SH-60B  weapon  systems.  This  information  is  used  by  the  missile  to 

align  its  inertial  navigation  system  and  to  navigate  to  the  target  unaided.  [LWSM92] 

E.  SUMMARY 

This  chapter  describes  the  tools  used  in  prosecuting  an  ASW  threat.  Most  of  the 
actual  tactics  involved  are  classified  and  beyond  the  scope  of  this  research.  The  purpose 
here  was  to  give  a  basic  knowledge  of  the  personnel,  sensors,  and  weapons  needed  to 
successfully  track  and  attack  a  subsurface  contact  so  that  they  could  be  reasonable 
simulated  in  NPSNET.  Implementation  of  classified  tactics  and  sensor/weapons  is 
independent  of  the  system  developed  for  NPSNET  by  this  research. 


30 


V.  HELICOPTER  CONTROL  MODELLING  IN  NPSNET 


A.  PREVIOUS  HELICOPTER  CONTROL  METHODOLOGY 

Motion  of  helicopters  in  NPSNET  prior  to  this  research  was  based  on  a  single  vector 
representing  the  velocity  of  the  helicopter.  The  vector  is  oriented  from  the  center  of  the 

helicopter  through  its  front,  as  shown  in  Figure  11.  Its  direction  in  NPSNET  world 
coordinates  is  calculated  from  the  heading,  pitch,  and  roll  angle  values  as  determined  from 
joystick  input.  Always  being  oriented  out  of  the  front  of  the  helicopter,  however,  means  that 
the  it  is  limited  to  motion  forwards  and  backwards. 
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The  speed  of  the  helicopter,  represented  by  the  velocity  vector’s  magnitude,  is 
determined  by  the  throttle  setting.  It  can  vary  anywhere  from  zero  to  the  maximum  speed 
of  the  helicopter,  defined  at  compile  time  to  be  100  m.p.h.,  regardless  of  its  attitude.  This 
further  limits  the  helicopter  to  forward  motion  without  the  capability  of  going  backwards, 
something  real  helicopters  are  quite  capable  of. 

Another  problem  here  is  that  this  model  allows  the  simulated  helicopter  to  remain 
stationary  in  space,  simulating  a  hover,  regardless  of  its  attitude.  As  explained  in  Chapter 
HI,  however,  real  helicopters  cannot  hover  at  pitch  and  roll  settings  other  than  zero.  A 
helicopter  must  first  decelerate  to  zero  airspeed  then  set  its  hover  attitude.  Any  other  pitch 
and  roll  setting  causes  the  helicopter  to  accelerate  out  of  a  hover. 

The  result  of  this  model  is  that  the  helicopter  has  freedom  of  motion  in  pitch,  roll, 
and  heading  angles,  and  in  its  positive  y  axis  only.  A  new  model  was  needed  to  accurately 
model  how  real  helicopters  can  move. 

B.  NEW  HELICOPTER  CONTROL  METHODOLOGY 

This  section  describes  the  methodology  for  calculating  the  helicopter’s  motion.  It 
describes  how  the  control  data  from  the  joystick,  throttle  and  rudder  pedals  is  interpreted  to 
calculate  velocity. 

Real  helicopter  motion,  described  in  Chapter  HI,  has  freedom  of  motion  in  pitch, 
roll,  and  heading  angles  as  well  as  positive  and  negative  x,  y,  and  z  axes.  This  allows  the 
helicopter  to  slide  left  and  right  (x  axis),  go  forward  and  backward  (y  axis),  and  go  up  and 
down  (z  axis).  This  unique  quality  of  helicopters  allows  independent  motion  in  any  of  these 
axes. 

To  accurately  model  this  ability,  a  four  axis  system  was  developed.  This  model, 
shown  in  Figure  11,  uses  control  inputs  to  calculate  the  speeds  in  the  x,  y,  and  z  axes,  and 
is  based  on  the  balance  of  forces  theory  of  aerodynamics  described  in  Chapter  III.  The  first 
step  is  to  extract  the  control  input  data  and  convert  that  into  magnitudes  for  the  four  vectors 
and  into  heading  pitch  and  roll  angles. 
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1.  Flight  Control  Data 
a.  Joystick  Input 

Figure  13  shows  how  the  raw  data  from  the  joystick  gets  converted  into 
values  for  the  x  and  y  axes  in  Figure  1 1 .  The  joystick  is  used  to  simulate  a  helicopter  cyclic, 
which  controls  the  helicopter’s  pitch  and  roll.  Raw  data  from  the  joystick  ranges  from  -1.0 
to  1.0  in  both  the  pitch  and  roll  channels.  In  the  pitch  channel,  -1.0  is  returned  by  the 
joystick  when  it  is  pushed  all  the  way  forward,  while  1 .0  is  returned  when  it  is  pulled  back. 
The  center  position  is  0.0,  and  values  in  this  range  indicate  how  far  forward  or  backward 
the  joystick  is  moved.  The  roll  channel  operates  in  a  similar  manner:  -1.0  is  the  leftmost 
position,  0.0  is  the  center,  and  1.0  is  the  rightmost  position,  with  varying  values  in  between. 
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Figure  13:  Joystick  Data  Flow 


The  raw  pitch  and  roll  data  is  used  to  find  the  magnitude  and  then  the 
direction  of  the  forward  and  lateral  velocity  vectors.  In  calculating  the  vector  magnitudes, 
raw  pitch  and  roll  data  are  first  used  to  calculate  forward  and  lateral  change  variables.  The 
equations  used  are: 

Aforward  =  -  (raw  pitch  data  *  0.09)  (Eq.  2) 

Alateral  =  raw  roll  data  *  0.09  (Eq.  3) 

These  equations  represent  the  amount  of  change  that  will  be  applied  to 
acceleration  in  each  of  these  channels.  For  example,  assume  that  the  helicopter  is  at  a 
constant  speed  with  the  joystick  in  the  center  position  (raw  pitch  and  roll  are  both  0.0).  If 
the  pilot  wishes  to  decelerate,  he  pulls  back  on  the  joystick.  The  raw  pitch  data  is  now  some 
value  between  0.0  and  1.0,  depending  on  how  far  the  joystick  was  pulled  back.  As  can  be 

seen  in  Eq.  2,  this  value  is  multiplied  by  the  dampening  constant  0.09  then  negated,  which 
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results  in  a  value  between  -1.0  and  0.0.  This  change  variable  is  later  added  to  forward 
acceleration,  indicating  that  the  acceleration  should  get  smaller.  In  the  case  of  the  example, 
since  the  helicopter  was  at  constant  airspeed,  there  was  no  acceleration,  so  acceleration 
becomes  negative  and  the  helicopter  decelerates  as  a  result.  This  works  in  a  similar  manner 
for  lateral  acceleration,  with  the  exception  that  the  value  is  not  negated,  as  shown  in  Eq.  3. 
The  reason  for  this  is  that  when  the  joystick  is  placed  to  the  right  of  its  center  position,  the 
raw  roll  data  ranges  between  0.0  and  1.0.  This  would  indicate  that  the  pilot  wishes  to 
accelerate  to  the  right.  The  helicopter’s  x  axis  is  also  positive  on  the  right.  So,  the  lateral 
change  data  is  directly  related  to  lateral  acceleration. 

The  next  step  in  calculating  the  magnitude  of  the  forward  and  lateral 
velocity  vectors  is  to  input  the  change  values  calculated  above  into  the  acceleration 
equations.  These  equations  are  as  follows: 

forward  accel  =  forward  accel  +  (A  forward  *  cos(  roll  angle)  )  (Eq.  4) 

lateral  accel  =  lateral  accel  +  A  lateral  (Eq.  5) 

lateral  accel  =  lateral  accel  +  (  A  lateral  /  forward  speed  )  (Eq.  6) 

In  the  example  above,  the  forward  change  variable  is  negative  since  the  pilot 

wishes  to  decelerate.  As  can  be  seen  in  Eq.  4,  this  value  is  multiplied  by  the  cosine  of  the 
roll  angle.  This  angle  was  calculated  in  the  previous  display  frame  and  is  used  as  a  starting 
point  for  calculating  the  roll  angle  in  the  current  frame.  The  cosine  of  the  roll  angle  is 
multiplied  by  the  forward  change  amount  to  reduce  the  amount  of  acceleration/deceleration 
as  angle  of  bank  increases.  Angle  of  bank  is  a  way  to  describe  roll  angles  without  the  use 
of  negative  values.  For  example,  30  degrees  of  roll  is  the  same  as  30  degrees  right  angle  of 
bank.  Similarly,  -30  degrees  of  roll  is  30  degrees  left  angle  of  bank. 

To  show  why  this  cosine  calculation  is  needed  in  the  forward  acceleration 
calculation,  assume  the  helicopter  is  rolled  to  the  right  90  degrees.  To  increase  the  rate  of 
turn,  the  pilot  pulls  back  on  the  joystick.  This  is  a  common  maneuver  in  forward  flight:  roll 
into  an  angle  of  bank,  then  pull  back  on  the  cyclic  to  increase  the  rate  of  turn.  If  the  cosine 
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calculation  isn’t  made,  forward  acceleration  will  decrease  and  the  helicopter  will  decelerate 
rapidly.  In  a  real  helicopter,  this  does  not  occur  due  to  the  fact  that,  at  90  degrees  angle  of 
bank,  pulling  back  on  the  joystick  will  not  result  in  the  helicopter  trying  to  climb.  It  only 
increases  how  fast  it  turns.  By  taking  the  cosine  of  the  roll  angle  and  multiplying  it  by  the 
forward  change  previously  calculated,  the  effect  of  the  forward  change  variable  is 
decreased  as  roll  angle  increases. 

Once  the  forward  change  value  is  multiplied  by  the  cosine  of  the  roll  angle, 
this  value  is  added  to  the  forward  acceleration  value  from  the  previous  display  frame.  The 
effect  here  is  that  acceleration  of  the  helicopter  is  smooth  and  reacts  slowly  to  the  input 
changes  by  the  pilot. 

Calculation  of  lateral  acceleration  operates  in  a  similar  manner  to  forward 

acceleration  except  that  there  is  no  adjustment  made  as  a  result  of  roll.  In  Eq.  5,  the  lateral 
change  amount  has  its  full  effect  on  acceleration  when  the  helicopter  is  flying  slower  than 
25  miles  per  hour  (m.p.h.).  So,  at  low  airspeeds,  the  helicopter  can  accelerate  into  a  left  or 
right  slide  at  its  maximum  rate.  As  airspeed  increases  above  25  m.p.h.,  however,  the  effect 
of  the  lateral  change  amount  on  lateral  acceleration  is  decreased  by  the  amount  of  forward 
airspeed,  as  shown  in  Eq.  6.  This  simulates  the  airstream  acting  on  the  fuselage  at  higher 
forward  speeds  and  thereby  restricting  lateral  acceleration.  Above  forward  speeds  of  50 
m.p.h.,  lateral  speed  and  acceleration  are  set  to  zero  to  make  the  helicopter  easier  to  fly  for 
non-helicopter  pilots. 

To  complete  the  calculation  of  the  forward  and  lateral  vector  magnitudes, 
the  forward  and  lateral  accelerations,  respectively,  are  dampened  and  added  to  the 
magnitudes  from  the  previous  display  frame.  The  equations  for  calculating  the  magnitudes, 
which  is  the  speed  the  helicopter  will  travel  in  its  x  and  y  axes,  are  as  follows: 

forward  speed  =  forward  speed  +  (  forward  accel  *  0.1)  (Eq.  7) 

lateral  speed  =  lateral  speed  +  (  lateral  accel  *  0.1)  (Eq.  8) 
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Acceleration  values  are  dampened  in  Eq.  7  and  Eq.  8  before  being  added  to 
previously  calculated  speed  values  to  provide  realistic  helicopter  acceleration  based  on 
control  inputs.  The  magnitudes  achieved  from  these  equations  are  later  used  to  scale  the 
forward  and  lateral  vectors,  respectively,  for  ultimately  calculating  the  helicopter’s 
velocity. 

As  seen  in  Figure  13,  the  joystick  data  is  also  used  to  calculate  heading, 
pitch  and  roll  angles  based  on  their  values  from  previous  display  frames.  No  significant 
changes  were  made  to  these  calculations  from  the  previous  helicopter  control  model  as  the 
angles  calculated  appear  realistic  enough  for  the  model  resulting  from  this  research.  The 
only  change  to  these  angle  calculations  was  to  add  the  capability  to  use  rudder  pedals,  as 
explained  in  the  following  section. 

b.  Rudder  Pedal  Input 

Raw  data  from  the  rudder  control  pedals  varies  from  -1.0  (left  pedal  full 
forward)  to  0.0  (pedals  centered)  to  1.0  (right  pedal  full  forward).  This  data  is  used  to 

calculate  heading  only,  as  shown  in  Figure  14.  On  the  ground  or  at  slow  airspeeds  (less  than 
25  m.p.h.),  raw  data  from  the  rudder  pedals  manipulates  the  heading  angle  from  the 
previous  display  frame.  This  allows  the  helicopter  to  rotate  around  its  z  axis. 

At  airspeeds  higher  than  25  m.p.h.,  raw  rudder  information  is  combined 
with  heading  and  roll  angle  data,  raw  pitch  data  from  the  joystick,  and  the  calculated 
forward  airspeed  to  calculate  the  new  heading.  Most  elements  of  this  calculation  are  from 
the  original  helicopter  control  model.  The  last  part  of  the  equation  (raw  rudder  data/ 
airspeed)  has  the  effect  of  changing  the  heading  based  on  how  far  a  rudder  pedal  is  pushed 
in.  Pushing  the  left  pedal  forward  halfway,  for  example,  causes  the  helicopter  to  execute  a 
moderate  rate  of  turn  to  the  left.  Pushing  the  left  pedal  all  the  way  forward,  however. 
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Figure  14:  Rudder  Pedal  Data  Flow 


Dividing  the  raw  rudder  data  by  the  calculated  forward  speed  reduces  the 
rate  of  turn  as  forward  airspeed  increases.  For  example,  if  the  left  pedal  is  pushed  all  the 
way  forward  at  30  m.p.h.,  the  helicopter  executes  a  moderate  turn  to  the  left.  Then  the 
helicopter  is  flying  at  1 80  m.p.h.  though,  the  same  pedal  position  results  in  a  very  slow  rate 
of  turn. 

c.  Throttle  Input 

Raw  throttle  data  is  used  to  calculate  the  amount  of  thrust  produced  by  the 
main  rotor  of  the  helicopter,  which  represents  the  magnitude  of  the  thrust  vector,  as  shown 

in  Figure  15.  The  data  ranges  from  0.0  in  the  rearward  position  to  1.0  in  the  forward 
position.  This  data  is  multiplied  by  a  constant  representing  the  maximum  amount  of  thrust 
can  be  achieved,  as  shown  in  the  following  equation: 

:hrust  setting  =  (raw  throttle  *  40,000)  -  (  forward  speed  *  111.1)  (Eq.  9) 
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Figure  15:  Throttle  Data  Flow 

By  multiplying  the  raw  throttle  data  by  40,000,  the  maximum  thrust 
available,  the  thrust  produced  is  then  a  percentage  of  the  maximum.  For  example,  having 
the  throttle  at  the  halfway  position  results  in  raw  throttle  data  of  0.5.  After  multiplying  this 
by  the  maximum  thrust  available,  the  thrust  produced  is  20,000  pounds. 

The  additional  adjustment  made  to  the  thrust  setting,  shown  in  Eq.  9, 
reduces  the  amount  of  thrust  produced  as  airspeed  increases.  This  is  done  to  simulate 
maximum  forward  airspeed  in  level  flight.  The  SH-60B  can  achieve  about  180  m.p.h.  in 
normal  level  flight.  To  simulate  maximum  forward  airspeed  in  level  flight,  the  thrust 
produced  by  the  helicopter  must  equal  the  weight  at  the  maximum  airspeed.  This  condition 
will  result  in  the  helicopter  being  flown  at  maximum  speed  with  maximum  power  applied 
while  maintaining  its  current  altitude.  If  the  pilot  flies  the  helicopter  any  faster  by  pushing 
the  joystick  forward  to  pitch  the  nose  down,  the  resultant  thrust  produced  will  decrease  to 
less  than  20,000  pounds.  Therefore,  the  helicopter  will  descend.  Also,  since  the  throttle  is 
already  at  maximum,  a  climb  cannot  be  initiated  by  adding  power  to  produce  more  thrust. 
The  only  way  to  climb  in  this  situation  is  to  pull  back  on  the  joystick  thereby  pitching  the 


helicopter’s  nose  up.  The  helicopter  will  climb  from  its  increase  in  angle  of  attack  to  the 
oncoming  airflow,  but  airspeed  will  also  decrease. 

To  reduce  the  thrust  produced  at  maximum  forward  airspeed  to  a  point 
where  it  equals  the  weight  of  the  helicopter,  a  constant  factor,  when  multiplied  by  the 
airspeed,  is  subtracted  from  the  thrust  calculation  resulting  from  the  throttle  position.  This 
is  shown  in  Eq.  9.  The  constant  111.1  produces  this  result.  It  is  calculated  from  the 
following  equation: 


helicopter  weight  (lbs)  , .. 

maximum  forward  speed  (mph)  M 

This  constant  affects  flight  at  any  airspeed,  not  just  flight  at  maximum 
forward  level  flight  airspeed.  The  effect  this  calculation  has  on  helicopter  control  is  that  as 
it  flies  at  a  faster  airspeed,  more  power  is  required  to  maintain  altitude.  This  adds  realism 
to  the  simulation  of  the  helicopter  as  well  as  limit  the  forward  speed  in  level  flight. 


2.  Vector  Calculations 

Once  the  magnitudes  of  the  forward  speed,  lateral  speed  and  thrust  vectors  in  Figure 
1 1  have  been  calculated  based  on  control  inputs,  their  directions  need  to  be  calculated.  This 
is  accomplished  using  the  heading,  pitch  and  roll  angle  calculations  and  the  Performer 
function  pfMakeEulerMat( ).  This  function  takes  the  heading,  pitch  and  roll  angles  and 
transforms  them  into  a  4-by-4  matrix  representing  the  amount  of  rotation  in  world 

coordinates  about  an  object’s  x,  y  and  z  axes  [HART94]. 

Once  the  matrix  is  formed,  another  Performer  function,  pfXformPt3(),  is  used  to 
transform  the  matrix  into  the  forward  velocity,  lateral  velocity,  and  total  lift  vectors,  shown 
in  Figure  16.  This  function  transforms  a  vector  expressed  in  the  object’s  coordinate  system 
into  a  vector  expressed  in  world  coordinates  [HART94].  It  is  used  here  to  transform  the  x, 
y  and  z  axes  in  the  helicopter’s  coordinate  system  to  the  same  axes  expressed  in  world 
coordinates.  The  helicopter’s  x  axis  is  the  lateral  velocity  vector,  its  y  axis  is  the  forward 
velocity  vector,  and  its  z  axis  is  the  thrust  vector. 
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Figure  16:  Total  Velocity  Vector 


The  next  step  is  to  normalize  these  vectors  using  the  Performer  function 
pfNormalizeVec3().  This  function  scales  a  vector  to  unit  length  [HART94].  It  is  used  here 
to  make  the  forward  velocity,  lateral  velocity,  and  thrust  vectors  a  uniform  length  to  then 
scale  them  to  the  desired  magnitudes  as  previously  calculated. 
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Next,  each  vector  is  scaled  to  its  respective  magnitude,  shown  in  Figure  16,  using 
the  pfScaleVec3()  Performer  function.  The  thrust  vector  is  scaled  to  the  thrust  setting,  the 
forward  velocity  vector  is  scaled  to  the  forward  speed,  and  the  lateral  velocity  vector  is 

scaled  to  lateral  speed.  These  vectors  now  represent  their  respective  vectors  in  Figure  11. 

3.  Weight  Vector 

The  fourth  vector  in  Figure  1 1  is  the  weight  vector.  This  vector  always  points  down 
from  the  center  of  the  helicopter  in  the  negative  z  axis  of  the  world  coordinate  system.  This 
is  accomplished  by  using  pfScaleVec3()  to  scale  the  world’s  z  axis  vector  of  unit  length, 
which  is  the  vector  <0, 0,  -1>,  to  the  constant  representing  the  helicopter’s  weight,  which 
is  set  to  20,000  pounds.  Since  this  vector  always  points  to  the  ground,  it  is  not  transformed 
from  the  4-by-4  Euler  matrix. 

4.  Velocity 

The  final  step  in  calculating  the  helicopter’s  motion  is  to  calculate  the  velocity 
vector.  This  is  done  by  adding  the  thrust,  weight,  forward  velocity  and  lateral  velocity 
vectors  to  obtain  the  total  speed  and  direction  of  the  helicopter. 

The  first  step  here  is  to  use  the  Performer  function  pfAddVec3()  to  add  the  forward 
velocity  and  lateral  velocity  vectors  into  a  temporary  vector.  This  represents  the  velocity  in 
the  helicopter’s  x-y  plane  and  is  later  added  to  the  thrust  and  weight  vectors  to  obtain  total 
velocity 

This  same  function  is  used  to  add  the  thrust  and  weight  vectors.  The  result 
represents  the  total  force  produced  by  the  main  rotor.  This  resultant  vector,  labeled  total  lift, 
determines  whether  the  helicopter  climbs  or  descends.  Since  the  helicopter’s  pitch  and  roll 

angles  determine  the  direction  of  the  total  lift  vector,  as  shown  in  Figure  3,  its  vertical 
component  (effective  lift),  must  counteract  the  helicopter’s  weight.  If  the  effective  lift  is 
greater  than  the  helicopter’s  weight,  it  will  climb;  if  it  is  less  than  the  weight,  the  helicopter 
descends.  If  they  are  the  same,  the  helicopter  will  maintain  its  altitude. 
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The  next  step  is  to  scale  the  total  lift  vector  just  calculated  using  pfScaleVec3().  The 
total  lift  vector  represents  the  force  produced  by  the  helicopter’s  main  rotor.  To  translate 

force  into  acceleration,  Eq.  1  is  used.  To  translate  the  total  lift  vector  into  acceleration,  it 
must  be  scaled  by  the  inverse  of  the  helicopter’s  mass,  a  constant  defined  at  compile  time. 
This  has  the  effect  of  shortening  the  total  lift  vector  without  changing  its  direction.  This 
resultant  vector  is  scaled  again  with  pfScaleVec3( )  by  A  time,  the  elapsed  time  between  the 
last  display  frame  and  the  current  one,  to  change  acceleration  into  velocity.  The  total  lift 
vector  now  represents  the  motion  of  the  helicopter  resulting  from  the  lift  produced  by  the 
helicopter  to  counteract  its  weight. 

Finally,  the  temporary  vector  representing  the  helicopter’s  x-y  plane  velocity  and 
the  total  lift  vectors  are  added  using  pfAddVec3().  This  velocity  is  then  used  to  calculate  the 
helicopter’s  position  in  the  world  coordinate  system  for  the  next  display  frame. 

To  make  the  helicopter  easier  to  fly,  limits  were  programmed  into  this  system  to 
prevent  the  helicopter  from  flying  to  fast  sideways  or  backwards.  An  SH-60B  is  limited  to 

flying  at  about  40  m.p.h.  in  sideways  or  rearward  flight  [NTPS90] .  The  reason  for  this  limit 
is  to  prevent  damage  to  the  helicopter  resulting  from  extreme  aerodynamic  situations.  The 
programmed  limit  is  therefore  40  m.p.h.  for  both  sideways  and  rearward  flight.  Limiting 
the  program  makes  the  simulated  helicopter  easier  to  control  for  inexperienced  users  and 
prevents  flight  in  unusual  aerodynamic  situations,  which  are  beyond  the  scope  of  this 
research. 


5.  Ground  Motion 

The  main  difference  between  calculation  of  motion  when  the  helicopter  is  on  the 
ground  versus  when  it  is  in  the  air  is  that  there  can  be  no  sideways  motion.  This  is  due  to 
the  helicopter’s  landing  gear,  which  only  allows  it  to  travel  forwards  and  backwards.  As  a 
result,  no  lateral  speed  need  to  be  calculated. 

As  for  the  forward  motion  calculations,  the  aerodynamics  that  apply  to  a  helicopter 
in  flight  also  apply  to  one  operating  on  the  ground.  Forward  motion  is  caused  by  creating 
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enough  effective  thrust,  shown  in  Figure  3,  to  overcome  the  drag  caused  by  the  contact  of 
the  landing  gear  with  the  ground.  To  move  forward  then,  power  must  be  added  and  forward 
pitch  must  be  applied. 

Real  helicopters  have  brakes  to  slow  down  and  stop  while  on  the  ground.  However, 
since  the  rudder  pedal  controls  utilized  for  this  research  have  no  brakes  equivalent,  the 
effect  must  be  simulated  through  other  means.  This  was  accomplished  by  programming 
pitch  inputs  from  the  joystick  to  control  acceleration.  To  slow  down  or  stop,  the  joystick 
must  be  pulled  back  and  the  throttle  increased. 

Heading  control  on  the  ground  is  the  same  as  it  is  in  the  air,  and  that  is  by  tail  rotor 
control  through  rudder  pedal  input.  Helicopter’s  do  not  have  directly  steerable  wheels  like 
automobiles  do.  Instead,  the  force  produced  by  the  tail  rotor  is  quite  sufficient  to  change  the 
helicopter’s  heading  since  the  torque  produced  by  the  main  rotor,  described  in  Chapter  III, 
is  still  present.  For  this  reason,  the  raw  data  from  the  rudder  control  pedals  controls  heading 
on  the  ground  just  as  it  does  in  a  hover. 

To  protect  the  landing  gear  from  damage,  real  helicopters  are  restricted  from  going 
above  certain  speeds  while  on  the  ground.  The  ground  speed  limit  for  the  SH-60B  is  about 
45  m.p.h.,  which  is  also  the  programmed  limit  for  speed  on  the  ground  [NTPS90].  This 
gives  the  user  adequate  control  and  realism  without  subjecting  the  helicopter  to  extreme 
situations.  These  kinds  of  situations  can  cause  serious  damage  to  helicopters,  and 
simulating  this  is  beyond  the  scope  of  this  research. 

In  addition,  moving  backwards  on  the  ground  is  not  permitted.  Although  most 
helicopters  can  taxi  backwards  easily,  it  is  not  practiced.  There  are  two  reasons  for  this.  The 
first  reason  is  that  since  helicopters  don’t  have  rear  windshields  like  automobiles  do,  it  is 
impossible  for  the  pilot  to  see  behind  the  helicopter  to  prevent  colliding  with  anything. 
Secondly,  to  taxi  backwards,  the  pilot  must  pull  back  on  the  cyclic  and  add  power  from  the 
collective.  Since  doing  this  causes  the  main  rotor  system  to  pitch  back,  the  possibility  exists 
for  the  main  rotor  blades  to  impact  the  rear  portion  of  the  fuselage. 
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If  the  pilot  flying  this  simulated  helicopter  lands  while  moving  faster  than  the 
maximum  forward  ground  limit  or  backwards,  the  helicopter  is  programmed  to  speed  up  or 
slow  down  gradually  until  ground  speed  is  within  limits.  Flight  can  be  achieved  again, 
however,  before  the  speed  is  in  limits. 

C.  SUMMARY 

The  purpose  of  this  portion  of  this  research  was  to  give  helicopters  in  NPSNET  the 
same  controllability  that  real  helicopters  have.  Due  to  the  aerodynamic  complexity  of  real 
helicopters,  though,  a  completely  physically  based  model  was  neither  attempted  nor 
desired.  The  purpose  here  is  twofold.  First,  NPSNET  must  still  be  used  by  anyone, 
including  those  with  no  helicopter  piloting  experience,  while  giving  the  user  some  idea  of 
what  it  takes  to  fly  a  real  helicopter.  The  previous  method  of  helicopter  control  gave  users 
adequate  control  of  a  helicopter,  but  sacrificed  too  much  realism  to  be  a  useful  indicator  of 
helicopter  flight. 

The  second  purpose  behind  this  design  is  to  execute  realistic  control  of  the 
helicopter  without  requiring  special  hardware  to  make  complex  calculations.  Since 
NPSNET  is  designed  to  run  on  commercial  off-the-shelf  computer  systems,  the  blade 
element  method  to  calculate  helicopter  aerodynamics  is  too  computationally  expensive  to 
be  useful  in  NPSNET.  The  simpler  balance  of  forces  method  provides  enough  realism  to 
the  simulation  without  sacrificing  speed  or  usability. 


VI.  INTERFACE  FOR  MULTIPLE  WORKSTATION  ASW 


A.  INTERFACE  PANEL  DESIGN 

As  mentioned  in  Chapter  n,  the  Panel  interface  designed  by  Chris  McMahan 
provides  a  useful  starting  point  to  implement  an  ASW  interface.  This  chapter  describes  the 
shortcomings  of  the  original  system  and  the  changes  made  to  the  system  for  this  research 
to  provide  ASW  functionality. 

B.  COMMUNICATION  WITH  NPSNET 
1.  Original  Implementation 

Communications  between  the  interface  Panel  and  a  workstation  running  NPSNET 
in  remote  mode  are  conducted  through  a  single  socket  structure.  This  structure,  called  a 

GUI_MSG_DATA  packet,  is  shown  in  Figure  18.  This  packet  is  used  to  pass  control  and 
weapons  information  between  NPSNET  and  the  Panel  across  the  network. 

The  proper  use  of  this  packet  is  shown  in  Figure  19.  In  this  case,  one  Panel  is  being 
used  in  conjunction  with  one  workstation  running  NPSNET  in  remote  mode.  Remote  mode 
means  that  the  Panel  displays  velocity  and  position  information  about  the  NPSNET  vehicle, 
herein  called  the  host  vehicle,  and  can  be  used  to  control  that  vehicle.  This  mode  is  turned 
on  when  NPSNET  is  initialized  with  the  “-r”  command  line  switch.  This  allows  NPSNET 
and  the  Panel  to  communicate  by  passing  the  GUI_MSG_DATA  packet  over  the  network. 
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typedef  struct  { 

double  status; 
unsigned  short  type; 
unsigned  short  length; 

//  throttle  data  required  to  read  the  throttle  position  (-1 .0  to  1 .0)  and  to 
//  set  the  throttle  input  with  the  scale  widget 
float  throttleSetting; 

//joystick  data  required  to  read  the  joystick  position  and  set  input  as  required 
//  (each  is  between  -1.0  and  1.0) 

float  joystickX; 
float  joystickY; 

//  vehicle  settings  read  from  NPSNET  only  (not  sent  from  interface) 
float  positionX; 
float  positionY; 
float  positionZ; 

float  altitude; 
float  heading; 
float  pitch; 
float  roll; 
float  velocity; 

float  gunAzimuth; 
float  gunElevation; 

Entity!  DvehiclelD; 

//flag  settings  to  execute  NPSNET  actions 
EntitylD  targetVehiclelD; 

BYTE  attachMode;  //including tether,  attach,  target,teleport 

BYTE  weaponsMode;  //including  primary,  secondary, tertiary,  targetingEnable 

BYTE  hudMode;  //  including  hudEnable 

BYTE  environmentMode;  //including fogEnable,  wireframeEnable,  textureEnable, 
//  cameraEnable 

//variable  settings  to  control  NPSNET  functions 
BYTE  fogSetting; 

BYTE  hudSetting; 

//NEW  -  data  passed  to  NPSNET  about  FTP  use  and  position 
int  FTPon; 
float  FTPXposit; 
float  FTPY  posit; 

}  GULMSGJDATA; 


Figure  18:  GUI_MSG_DATA  structure 
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Figure  19:  Single  Panel/Single  NPSNET 
Cooperation 

The  use  of  this  method  fails  when  more  than  one  workstation  is  running  NPSNET 
in  remote  mode,  as  shown  in  Figure  20.  In  this  example,  Workstations  #2  and  #3,  each 
running  NPSNET  in  remote  mode,  both  communicate  to  the  Panel  application  through  the 
passing  of  GUI_MSG_DATA  packets  over  the  network.  The  Panel  becomes  unusable 
since  conflicting  information  is  received  from  different  NPSNET  host  vehicles.  In  addition, 
if  the  Panel  sends  controlling  information  to  NPSNET,  it  is  possible  for  the  host  vehicles 
being  simulated  on  Workstations  #2  and  #3  to  be  controlled  by  the  one  Panel  on 
Workstation  #1.  This  is  generally  not  a  realistic  scenario:  one  person  cannot  drive  two 
separate  vehicles. 

The  situation  becomes  even  more  confusing  when  there  are  multiple  interface 
Panels  and  multiple  workstations  running  NPSNET  in  remote  mode,  as  in  Figure  21.  Each 
panel  could  control  both  NPSNET  host  vehicles,  and  each  Panel  receives  conflicting 
GUI_MSG_DATA  information  from  both  host  vehicles. 
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Figure  20:  Single  Panel/Multiple  NPSNET 
Problem 
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Figure  21:  Multiple  Panel/Multiple  NPSNET 
Problem 
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2.  Exclusive  Two-way  Communication  with  NPSNET 

As  described  in  Chapters  in  and  IV,  helicopter  ASW  is  conducted  through  the 
utilization  of  each  member  of  the  helicopter’s  crew.  Each  crewmember  performs  specific 
functions  while  supplementing  the  duties  of  fellow  crewmembers. 

The  functionality  of  the  interface  Panel  provides  an  adequate  framework  to  model 
helicopter  ASW.  However,  to  model  the  crew  coordination  concept,  it  is  necessary  that  one 
Panel  communicate  with  one  NPSNET  host  vehicle,  regardless  of  how  many  workstations 
are  running  NPSNET  in  remote  mode. 

The  approach  taken  to  accomplish  this  was  to  have  one  NPSNET  workstation 

running  in  remote  mode  cooperate  with  one  Panel,  as  shown  in  Figure  22.  Each  workstation 
supplies  address  information  to  the  GUI_MSG_DATA  packets  it  generates.  When  either 
workstation  receives  the  packets,  it  compares  the  address  information  in  the  packet  to  the 
address  information  stored  in  the  program  about  which  workstation  it  is  cooperating  with. 
If  the  addresses  match,  the  state  of  the  respective  program  is  updated.  Otherwise,  the 
GUI_MSG_DATA  packets  are  discarded. 


Figure  22:  Desired  Multiple  Panel/Multiple 
NPSNET  Cooperation 
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a.  Communication  from  the  Interface  Panel  to  NPSNET 

The  first  step  to  accomplish  this  was  to  change  how  the  interface  panel  is 
initialized  so  that  a  specific  workstation  could  be  designated  as  the  cooperative 
workstation.  This  designated  workstation  will  run  NPSNET  in  remote  mode,  and  it  is  the 
only  workstation  which  the  Panel  will  communicate  with.  A  new  command  line 
initialization  switch  was  implemented  to  supply  the  necessary  workstation  identification 
information  to  the  Panel  at  start-up. 

To  initialize  the  Panel  in  this  mode,  the  new  switch  uses  the  character  ‘s’  to 
designate  a  session.  The  syntax  of  the  switch  is  “-s  workstation  name>”.  When  the  name 
of  a  valid  workstation  is  supplied,  the  identification  information  allows  both  NPSNET  and 
the  Panel  to  filter  out  unwanted  GUI_MSG_DATA  packets  from  other  workstations.  The 
workstation  name  is  read  from  the  command  line  at  initialization  and  then  verified  in  the 

datafiles/ho sts.dat  file,  an  example  of  which  is  shown  in  Figure  23.  The  two  pieces  of 
applicable  information  are  the  second  and  third  fields  of  the  file,  indicating  the  site  number 
(all  36  in  the  example)  and  the  host  number  (the  number  following  36).  This  information  is 
stored  in  the  variable  “npsnetAddress.address.site”  and  “npsnetAddress.address.host”, 
respectively,  as  part  of  the  GLOBAL_DATA  structure  defined  in  global.h. 

After  initialization  of  the  Panel  in  complete,  it  can  now  communicate  with 
the  desired  workstation  running  NPSNET  in  remote  mode  by  passing  the 
GUI_MSG_DATA  packet.  When  a  change  is  made  to  the  Panel’s  state  that  requires  a 
similar  change  of  state  in  NPSNET,  the  applicable  data  is  sent  to  the  Message  class  of  the 

Panel  [MCMA95].  The  Message  class  then  generates  a  GUI_MSG_DATA  packet,  writing 
the  applicable  information  to  the  appropriate  field  of  the  packet.  The  last  step  performed  by 
the  Message  class  is  to  write  the  “npsnetAddress.address”  data  field  to  the  “vehiclelD”  field 
of  the  GUI_MSG_DATA  packet  and  write  the  packet  to  the  network.  This  is  performed  in 
Message::writeSocket(),  seen  in  Appendix  B  beginning  on  line  5. 
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bessie 

36  1  ecO 

betsie 

36  2  ecO 

black 

36  3  ecO 

bond 

36  4  ecO 

bossie 

36  5  ecO 

bradley 

36  6  ecO 

clancy 

36  7  ecO 

clarabell 

36  8  ecO 

cool 

36  9  ecO 

daisy 

36  10  ecO 

dude 

36  11  ecO 

elsie 

36  12  ecO 

elvis 

36  13  etO 

fietch 

36  14  ecO 

gnarly 

36  15  ecO 

grant 

36  16  ecO 

gravy 1 

36  17  ecO 

gravy2 

36  18  ecO 

gravy  3 

36  19  etO 

gravy  5 

36  20  etO 

holmes 

36  21  ecO 

like  36  22  ecO 

meatloaf 

36  23  etO 

medusa 

36  24  ecO 

minotaur 

36  25  ecO 

patton 

36  26  ecO 

pershing 

36  27  ecO 

rambo 

36  28  ecO 

ridgeway 

36  29  ecO 

totally 

36  30  ecO 

trouble 

36  31  ecO 

turing 

36  32  ecO 

chaos  36  33  ecO 

federation.arl.mil  36  34  etO 

orion.arl.mil  36  35  etO 

hred-iport3.arl.mil  36  36  etO 

hred-iport2.arl.mil  36  37  ecO 

Figure  23:  Example  hosts.dat  File 


When  any  NPSNET  workstation  running  in  remote  mode  receives  this 
packet,  it  first  compares  the  “vehiclelD”  field  in  the  packet  with  its  own  identification 
information,  which  is  obtained  from  the  same  hosts.dat  file  used  by  the  Panel.  This  is 
performed  in  the  main  application  loop  of  NPSNET  in  the  source  file  main.cc,  shown  in 

Appendix  A  beginning  on  line  9.  If  there  is  a  GUI_MSG_DATA  packet  available  to  be 
read,  and  if  the  “vehiclelD. address”  field  of  the  packet  matches  the  workstation’s  own 
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“DIS_address”,  the  rest  of  the  information  in  the  packet  is  assigned  to  the  appropriate  place 
to  update  the  NPSNET  host  vehicle’s  state.  If  the  GUI_MSG_DATA  “vehiclelD.address” 
field  does  not  match  the  workstation’s  own  address  information,  the  packet  is  discarded. 

The  situation  described  here  is  initiated  when  the  Panel  has  remote  control 
of  the  NPSNET  host  vehicle  and  any  control  input  changes  are  made.  This  includes 
weapons  fire  information  and  the  newly  implemented  Fly-to-Point  data,  both  described 
later  in  this  chapter.  This  filtering  of  GUI_MSG_DATA  packets  now  allows  one  Panel  to 
cooperate  with  a  host  vehicle  being  simulated  on  one  workstation,  while  other  Panels 
communicate  with  their  own  NPSNET  host  vehicles.  This  operates  as  shown  in  Figure  22. 

b.  Communication  from  NPSNET  to  the  Interface  Panel 

The  previous  section  described  the  situation  where  the  interface  Panel  sends 
control  information  to  NPSNET  running  in  remote  mode.  NPSNET  also  sends  the 
GUI_MSG_DATA  packet  to  the  Panel  when  the  host  vehicle  changes  its  state.  This  is 
necessary  when  the  host  vehicle  changes  any  data  that  gets  repeated  on  the  Panel’s  display, 
including  heading,  pitch,  roll,  position,  velocity,  and  altitude. 

To  maintain  the  capability  shown  in  Figure  22,  the  Panel  must  also  filter  out 
any  GUI_MSG_DATA  packets  it  receives  from  unwanted  NPSNET  workstations  running 
in  remote  mode.  This  is  done  in  a  similar  manner  as  when  the  Panel  generates  the  packets 
for  NPSNET,  with  the  exception  that  NPSNET  puts  its  own  address  information  into  the 
packet’s  “vehiclelD.address”  field. 

In  each  cycle  of  NPSNET’s  main  application  loop,  every  field  of  the 
GUI_MSG_DATA  packet  that  involves  control  data  is  updated  with  the  host  vehicle’s 

appropriate  information,  shown  in  Appendix  A  starting  on  line  82.  As  can  be  seen  on  lines 
94  an  95,  the  workstation’s  own  address  information  is  written  to  the  “vehiclelD.address” 
field  of  the  GUI_MSG_DATA  packet.  After  five  cycles  of  the  main  application  loop,  the 
latest  packet  to  be  updated  is  sent  to  the  network. 
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When  the  Panel  receives  a  GUI_MSG_DATA  packet  from  NPSNET,  it  first 
compares  the  “vehiclelD. address”  field  of  the  packet  with  the  “nspnetAddress.address” 
variable  assigned  upon  initialization  and  mentioned  in  the  previous  section.  This  is  shown 

in  the  readSocket()  function  beginning  on  line  26  of  Appendix  B.  If  the  address  information 
matches,  the  packet  was  sent  from  the  cooperating  workstation  that  was  designated  with  the 
“-s”  switch.  Therefore,  the  packet  is  sent  to  the  appropriate  Panel  classes  to  update  any 
displayed  data,  just  as  had  been  done  in  the  Panel’s  original  implementation  [MCMA95]. 
However,  if  the  addresses  differ,  the  packet  is  discarded  and  the  Panel’s  display  is  not 
updated. 

With  this,  the  two-way  exclusive  communication  that  was  the  goal  of  this 

research  and  illustrated  in  Figure  22  has  been  achieved.  Both  NPSNET  and  the  Panel  get 
updated  by  receipt  of  GUI_MSG_DATA  packets  addressed  to  or  from  the  desired 
workstation  while  all  others  are  discarded. 

C.  GUI_MSG_DATA  PACKET  UTILIZATION  FOR  ASW 

Two  of  the  duties  listed  in  Chapter  IV  required  by  the  ATO  in  an  ASW  helicopter 
are  to  navigate  to  target  areas  for  employment  of  sensors  and  weapons,  and  to  direct 
sonobuoy  and  weapon  delivery.  These  duties  require  communication  between  the  pilot, 
who  is  flying  the  helicopter,  and  the  ATO.  This  crew  coordination  must  be  conducted 
efficiently  to  adequately  prosecute  a  submarine  threat. 

With  the  two-way  exclusive  communication  implemented  between  the  interface 
Panel  and  NPSNET,  the  crew  coordination  concept  can  now  be  modelled.  By  incorporating 
navigation  and  ASW  weapons  delivery  functionality  into  the  Panel,  the  functions 
performed  by  the  ATO  are  simulated.  The  data  generated  by  the  ATO  is  transmitted  to  the 
selected  NPSNET  workstation  operating  in  remote  mode  to  simulate  crew  coordination. 
Host  vehicle  data  is  also  transmitted  from  the  pilot’s  workstation  back  to  the  ATO’s  Panel 
so  the  ATO  can  back  up  the  pilot  in  maintaining  safety  of  flight.  All  of  this  is  performed 
through  the  use  of  the  GUI_MSG_DATA  packet. 
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1.  Fly-to-Point  Navigation 

The  way  the  ATO  informs  the  pilot  where  to  fly  the  helicopter  is  through  the  use  of 
fly-to-points  (FTP).  During  an  ASW  mission,  the  ATO  decides  where  to  deploy  sonobuoys 
and  launch  weapons.  The  location  he  decides  on  is  a  precise  location  based  on  the  tactics 
used  to  prosecute  the  submarine.  The  ATO  enters  FTP  information  onto  his  tactical  display 
as  a  prioritized  list  of  locations.  The  highest  priority  FTP  is  the  one  the  pilot  will  fly  to  next. 

The  information  regarding  this  FTP  is  displayed  to  the  pilot  as  a  heading  cursor  on 
his  compass.  The  pilot  turns  the  helicopter  until  its  heading  and  the  heading  to  the  cursor 
are  the  same.  Once  the  helicopter  reaches  this  FTP,  the  point  disappears,  which  is  called 
capturing  the  FTP.  The  ATO  can  then  launch  a  sonobuoy  or  weapons  as  he  desires.  The 
pilot  also  gets  information  about  the  FTP  with  the  next  highest  priority  after  capturing  the 
current  one. 

To  model  this  functionality,  the  ability  of  the  ATO  to  designate  FTP’s  on  the  Panel 
and  communicate  their  location  to  the  pilot’s  NPSNET  workstation  was  implemented.  This 

is  shown  in  Figure  24.  The  left  side  of  the  figure  shows  the  radar  display  of  the  Panel,  which 
is  used  as  the  ATO’s  tactical  display.  It  shows  the  helicopter  in  the  center,  with  a  line  from 
its  center  pointing  down  and  to  the  left  to  indicate  the  helicopter’s  heading.  The  two 
triangles  are  FTP’s,  with  the  one  below  the  helicopter  having  highest  priority  and  the  one 
above  having  a  lower  priority.  The  right  side  of  the  figure  shows  the  compass  on  the  heads- 
up  display  (HUD)  for  this  same  helicopter  in  NPSNET.  The  ‘ * ’  next  to  the  ‘S’  indicates  to 
the  pilot  which  way  to  head  to  capture  the  FTP,  in  this  case,  to  turn  left  from  heading  234. 
How  the  ATO  enters  FTP  information  onto  the  display  is  shown  in  the  next  chapter. 

When  the  ATO  enters  an  FTP  onto  the  Panel’s  radar,  the  function 
Message::FTPChanged()  is  called,  which  generates  a  GUI_MSG_DATA  packet  to  notify 
the  pilot  where  to  go.  The  FTP  location  information  is  written  in  world  coordinates  to  the 
“FTPxposit”  and  “FTPyposit”  fields  of  the  GUI_MSG_DATA  packet,  seen  at  the  bottom 
of  Figure  18.  The  packet  is  then  sent  to  NPSNET  over  the  network  as  described  earlier. 
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a)  Panel  radar  display  b)NPSNET  HUD  display 


Figure  24:  Communication  of  FTP 
Information 

When  the  pilot’s  NPSNET  workstation  receives  the  packet,  the  FTP  position  data 
is  written  to  the  FTP  data  fields  of  the  PASS_DATA  structure  defined  in  draw.h  in  the 

source  code  of  NPSNET.  This  assignment  is  shown  on  lines  39  through  41  in  Appendix  A. 
This  data  is  then  used  by  the  vehicle_hud_draw()  function  in  NPSNET’ s  vehicle. cc  to 
display  the  heading  cursor  on  the  pilot’s  compass.  This  data  is  displayed  until  the  FTP  is 
captured  or  the  ATO  deletes  this  FTP  or  designates  a  new  one  on  the  radar  display  of  the 
Panel. 


2.  Weapons  Delivery 

Once  the  ATO  has  communicated  to  the  pilot  where  to  fly  the  helicopter,  it  is  up  to 
the  ATO  to  launch  weapons  and  sonobuoys,  as  described  earlier.  Since  weapons  in 
NPSNET  are  themselves  entities,  generation  of  the  weapon  is  handled  by  the  vehicle’s 
workstation,  which  sends  DIS  entity  state,  fire,  and  detonation  PDU’s  regarding  the 
weapon  to  the  other  vehicle’s  participating  in  the  simulation. 
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To  model  this  capability,  use  of  the  GUI_MSG_DATA  packet  is  again  needed. 
When  the  ATO  generates  a  torpedo  or  missile  launch  from  the  weapons  buttons  on  the 
Panel,  shown  in  Figure  17,  a  GUI_MSG_DATA  packet  is  generated  by  calling  the  weapon 

launch  functions  of  the  Message  class.  These  are  shown  in  Appendix  B  beginning  on  line 
155.  The  data  sent  to  NPSNET  is  in  the  form  of  a  byte  called  “weaponsMode”  in  the 

GUI_MSG_DATA  packet,  as  seen  in  Figure  18.  It  specifies  whether  to  launch  the  vehicle’s 
primary,  secondary  or  tertiary  weapon.  The  packet  is  then  sent  onto  the  network. 

When  the  NPSNET  workstation  meant  to  get  the  packet  receives  it,  the 
“weaponsMode”  byte  value  is  stored  in  a  variable  called  “the_button”,  seen  on  line  21  of 

Appendix  A.  If  the  vehicle  type  is  an  ASW  helicopter,  then  “the_button”  is  compared  with 
constants  defining  primary,  secondary,  or  tertiary  weapons.  Whichever  value  matches,  a 
firebuttonhit()  function  call  is  made  to  the  Munitions  class  in  NPSNET,  and  the  appropriate 
weapon  is  fired  just  as  if  the  person  at  the  flight  controls  launched  it. 

Since  the  ATO  generally  launches  the  torpedoes  or  missiles  in  an  SH-60B 
helicopter,  the  capability  was  given  to  have  the  ATO  running  the  Panel  be  able  to  launch 
weapons  even  if  the  pilot  operating  the  vehicle  in  NPSNET  has  flight  control  over  the  host 
vehicle.  This  simulates  additional  crew  coordination  functionality  between  the  pilot  and 
ATO.  The  pilot  also  still  has  the  ability  to  launch  weapons  from  buttons  on  the  flight 
controls  or  from  the  keyboard. 

D.  SUMMARY 

The  communications  conducted  between  the  interface  Panel  and  NPSNET  prior  to 
this  research  contained  adequate  framework  to  simulate  crew  coordination.  By 
programming  both  the  Panel  and  NPSNET  to  filter  out  unwanted  GUI_MSG_DATA 
packets,  a  single  Panel  can  now  communicate  with  a  single  NPSNET  entity  while  other 
Panels  operate  in  conjunction  with  their  entities.  These  crew  coordination  concepts  are 
shown  through  the  added  capability  of  passing  FTP  data  from  the  Panel  to  the  NPSNET 
entity,  and  through  the  flight  data  passed  from  the  entity  to  the  Panel  for  display. 


59 


VII.  ASW  SYSTEM  DESCRIPTION 


A.  INTRODUCTION 

This  chapter  describes  the  ASW  functionality  added  to  NPSNET  and  the  interface 
Panel,  including  a  description  of  the  radar  display,  how  to  enter  and  manipulate  Fly-to- 
Points  (FTP),  how  sonobuoys  are  modelled,  and  how  to  launch  torpedoes  and  missiles.  The 
ASW  functionality  is  available  only  when  NPSNET  and  the  interface  Panel  are  initiated  in 
the  correct  mode.  NPSNET  must  be  initialized  as  an  SH-60B  helicopter  in  remote  mode  as 
the  host  vehicle.  This  is  accomplished  by  including  the  “-v”  command  line  switch  with 
“sh60”  as  its  argument.  Remote  mode  is  turned  on  by  including  the  “-r”  switch  at 
initialization,  which  allows  NPSNET  to  send  and  receive  GUI_MSG_DATA  packets. 

To  activate  the  ASW  functionality  in  the  interface  Panel,  it  must  be  initialized  in 
session  mode  with  the  “-s”  command  line  switch  with  the  name  of  the  host  vehicle’s 
workstation  as  its  argument,  as  described  in  Chapter  VI.  For  example,  if  we  want  to  control 
the  NPSNET  host  vehicle  on  the  workstation  “elvis”,  initialized  as  described  above,  then 
the  Panel  must  be  initialized  from  another  workstation  with  the  argument  “-s  elvis”.  This 
allows  the  Panel  to  send  and  receive  GUI_MSG_DATA  packets,  and  enables  packet 
filtering  for  both  NPSNET  and  the  Panel,  also  described  in  Chapter  VI.  Other  ASW 
functionality  is  activated  by  selecting  “ASW  Helo”  from  the  Vehicle  menu  of  the  Panel. 

This  enables  FTP  and  sonobuoy  functionality.  Figure  17  shows  the  Panel  in  ASW 
Helicopter  mode. 

B.  PANEL  RADAR  DISPLAY 

The  ATO  in  an  SH-60B  has  a  tactical  display  used  for  viewing  sensor  data, 
managing  sonobuoys,  entering  FTP’s,  and  controlling  the  tactical  conduct  of  a  mission. 

This  display,  shown  in  Figure  6,  is  graphical  in  nature,  giving  the  ATO  a  picture  of  the 
ASW  situation. 
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The  SH-60B  tactical  display  is  simulated  in  this  research  through  the  use  of  the 
radar  display  on  the  interface  Panel.  The  basic  functionality  from  the  original 
implementation  of  the  Panel  remains  largely  unchanged  [MCMA95].  Its  function  is  to 
display  the  location  of  entities  in  the  virtual  environment  relative  to  the  host  vehicle’s 
location.  The  center  of  the  radar  display  represents  the  location  of  the  host  vehicle.  All  other 
entities,  whose  locations  are  determined  from  DIS  Entity  State  PDU’s  received  from  the 
network,  are  shown  on  the  radar  as  icons  representing  the  vehicles’  type. 

One  significant  change  made  to  the  radar  display  of  the  Panel  was  its  orientation. 
Originally,  the  heading  of  the  host  vehicle  determined  the  radar’s  orientation,  with  the 
vehicle’s  heading  pointing  up.  So,  the  radar  picture  rotated  as  the  host  vehicle  turned.  This 
was  an  unrealistic  depiction  of  a  radar’s  display,  and  can  get  confusing  for  the  user.  Real 
radar  displays  are  oriented  such  that  north  points  up  on  the  radar’s  display.  When  the 
vehicle  turns,  the  display  stays  oriented  towards  north  and  the  iconic  representation  of  the 
vehicle  turns.  The  icon  indicates  the  heading  of  the  helicopter  with  a  small  line  inside  of  the 
icon. 

To  simulate  this,  the  rotating  functionality  of  the  Panel’s  radar  display  was 
removed.  As  a  result,  north  points  up  on  the  display  regardless  of  vehicle  heading.  To 
indicate  the  host  vehicle’s  heading,  a  small  line  is  drawn  from  the  center  of  the  radar 

pointing  in  the  direction  of  the  host  vehicle’s  heading.  This  can  be  seen  in  Figure  25,  which 
shows  that  the  host  vehicle’s  heading  is  about  southwest. 

Additional  functionality  was  added  to  the  Panel’s  radar  display  to  allow  for  the 
display  and  management  of  FTP’s  and  sonobuoys.  The  source  code  for  the  Radar  class  of 
the  interface  Panel  is  contained  in  Appendix  C  and  Appendix  D. 

1.  Fly-to-Point  Management 

FTP’s  are  navigational  aids  used  by  the  ATO  to  tell  the  pilot  where  to  fly  the 
helicopter.  They  are  used  in  ASW  to  indicate  locations  for  sonobuoy  and  weapons 
deployment. 
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Figure  25:  FTP  Example 

In  the  interface  Panel,  FTP’s  are  entered  and  displayed  in  the  radar  display,  as 

shown  in  Figure  25.  Each  FTP  is  displayed  as  a  triangle  with  a  number  inside  indicating  its 
priority.  Up  to  six  FTP’s  can  be  entered  on  the  radar  display.  Source  code  for  displaying, 
entering,  deleting,  and  capturing  FTP’s  is  contained  in  Appendix  C  and  Appendix  D. 

a.  Entering  FTP’s 

Entering  FTP’s  onto  the  radar  display  is  made  possible  by  turning  on  the 
FTP  toggle  button,  as  shown  in  Figure  17.  New  FTP’s  appear  on  the  radar  display  at  the 
mouse  pointer’s  position  when  the  left  mouse  button  is  pressed  in  the  radar’s  display  area. 
If  there  are  a  maximum  number  of  FTP’s  in  the  system,  in  this  case  six,  no  more  can  be 
entered  until  one  of  the  existing  FTP’s  has  been  deleted  or  captured. 
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As  mentioned  earlier,  each  FTP  also  has  an  associated  priority,  which 
indicates  the  order  in  which  the  FTP’s  should  be  flown  to.  Newly  entered  FTP’s  have  the 
lowest  priority  of  those  in  the  system.  For  example,  if  there  are  three  FTP’s  currently 
entered  into  the  system,  the  next  FTP  will  have  priority  4,  assuming  that  none  of  the  original 
FTP’s  gets  deleted  from  the  system  before  the  new  one  is  entered.  If  there  are  no  FTP’s 
currently  in  the  system,  the  new  FTP  will  have  priority  1 . 

The  significance  of  the  highest  priority  FTP  (priority  1)  is  that  it  is  the 
position  selected  by  the  ATO  for  the  next  sonobuoy  or  weapon  launch.  As  such,  it  is  the 
only  FTP  whose  position  is  transmitted  to  the  host  vehicle,  which  is  described  in  Chapter 
VI. 


b.  Capturing  FTP’s 

When  the  helicopter  gets  within  a  certain  distance  of  the  highest  priority 
FTP,  it  is  deleted  from  the  system,  signifying  that  the  position  the  ATO  wanted  the  pilot  to 
fly  to  has  been  reached.  This  distance  is  calculated  as  a  horizontal  distance  since  FTP’s  are 
not  based  on  altitude.  The  maximum  distance  this  can  occur  is  defined  at  compile  time  to 
be  500  yards.  Hence,  when  the  helicopter  gets  within  500  yards  of  the  priority  1  FTP,  it  is 
captured.  Only  the  priority  1  FTP  can  be  captured. 

After  capturing  the  priority  1  FTP,  the  priorities  of  any  other  FTP’s  in  the 

system  are  increase  by  one.  So,  if  the  priority  1  FTP  in  Figure  25  is  captured,  it  is  removed 
from  the  radar  display,  and  the  priority  of  the  priority  2  FTP  becomes  priority  1,  whose 
location  is  then  transmitted  to  the  NPSNET  host  vehicle.  In  addition,  if  there  are  six  FTP’s 
in  the  system  prior  to  one  being  deleted  or  captured,  then  there  are  five  FTP’s  after.  In  this 
case,  another  FTP  can  then  be  added  to  the  system,  as  described  earlier. 

As  stated  before,  FTP’s  denote  the  locations  where  the  ATO  wishes  to  drop 
sonobuoys  or  torpedoes.  One  of  the  capabilities  of  the  SH-60B  is  that  it  can  automatically 
launch  sonobuoys  upon  the  capture  of  an  FTP.  To  simulate  this,  the  Panel  automatically 
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inserts  a  sonobuoy  into  the  system  when  capturing  an  FTP.  Sonobuoy  use  is  described  later 
in  this  chapter. 

c.  Deleting  FTP’s 

Occasionally,  the  ATO  may  wish  to  delete  an  FTP  from  the  system.  This  is 
done  when  the  ATO  wishes  to  reprioritize  them,  change  their  locations,  or  insert  new  ones 
if  the  maximum  number  is  already  in  the  system. 

Deleting  FTP’s  is  accomplished  on  the  Panel  by  first  turning  the  FTP  toggle 
button  off.  Then,  by  placing  the  mouse  pointer  on  a  currently  existing  FTP  and  clicking  the 
left  mouse  button,  the  FTP  disappears  from  the  radar  display.  In  addition,  remaining  FTP’s 
are  reprioritized,  if  necessary,  so  that  the  priorities  of  all  FTP’s  in  the  system  is  an 

increasing  sequence  (i.e.  no  priority  gaps).  This  is  shown  in  Figure  26.  On  the  left  side, 
there  are  four  FTP’s  with  priorities  1  though  4.  When  the  FTP  with  priority  2  is  deleted,  the 
rest  of  the  FTP’s  get  renumbered  such  that  the  FTP  with  priority  3  now  has  priority  2,  and 
the  FTP  with  priority  4  now  has  priority  3. 

2.  Sonobuoy  Usage 

As  described  in  Chapter  V,  sonobuoys  are  used  to  track  subsurface  contacts.  For 
this  research,  sonobuoys  are  modelled  only  as  part  of  the  interface  Panel.  The  reason  for 
this  is  that,  as  a  sensor,  the  sonobuoy  would  need  to  be  modelled  as  a  sensor  entity  in 
NPSNET  to  provide  the  necessary  information  to  other  vehicles  in  NPSNET  regarding  its 
characteristics.  This  would  necessitate  the  use  of  the  DIS  Emission  PDU,  currently 
unimplemented  in  NPSNET. 
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Figure  26:  Deleting  FTP’s 

To  model  sonobuoys  through  the  Panel,  the  weapons  launch  buttons  and  the  radar 
display  are  again  used.  This  allows  for  entering  sonobuoys  into  the  system,  displaying 
sonobuoy  locations,  and  displaying  subsurface  contact  information.  Sonobuoys  are 
displayed  as  a  circle  around  the  letter  ‘S’  with  a  line  indicating  the  submarine’s  position,  as 

shown  in  Figure  27. 

a.  Entering  Sonobuoys 

Sonobuoys  can  be  entered  in  to  the  system  automatically  or  manually.  Since 
sonobuoys  are  launched  from  the  helicopter’s  current  location,  sonobuoys  first  appear  in 
that  location.  The  sonobuoy  remains  in  that  location  for  the  duration  of  the  simulation. 

To  automatically  enter  a  sonobuoy  into  the  system,  the  helicopter  must 
capture  a  FTP,  as  described  earlier.  Manually  launching  sonobuoys  is  accomplished  by 
pressing  the  sonobuoy  button  next  to  the  radar  display.  A  maximum  of  25  sonobuoys  can 
be  entered  into  the  system.  There  is  no  difference  in  the  functionality  of  manually  launched 
sonobuoys  versus  those  automatically  launched. 
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Figure  27:  Sonobuoy  Examples 


b.  Sonobuoy  Contact  Information 

The  type  of  sonobuoy  modelled  in  the  interface  Panel  is  an  active  sonobuoy. 
As  described  in  Chapter  IV,  active  sonobuoys  reveal  bearing  and  distance  information  from 
the  sonobuoy  to  the  subsurface  contact  by  transmitting  a  sonar  signal  and  receiving  the 
sonar  echo.  Due  to  their  limited  power,  both  active  and  passive  sonobuoys  are  generally 
considered  short  range  sensors  for  tracking  submarines. 

Sonobuoys  simulated  in  the  Panel  do  not  detect  subsurface  contacts  by 
listening  for  acoustic  signals.  This  is  because  entities  in  NPSNET  transmit  DIS  Entity  State 
PDU’s,  which  have  no  acoustic  information.  The  Panel,  however,  receives  these  PDU’s  to 
be  able  to  display  these  entities  on  the  radar  display.  By  extracting  vehicle  type  and  position 
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information  from  the  PDU’s,  the  Panel  system  knows  the  location  of  all  vehicles  in  the 
simulation,  including  submarines. 

To  display  the  location  of  a  submarine  relative  to  a  sonobuoy,  the  distance 
from  the  sonobuoy  to  the  submarine  is  tested.  To  simulate  the  limited  range  of  sonobuoys, 
the  location  of  a  submarine  is  displayed  only  if  its  distance  is  less  than  1000  yards.  If  it  is, 
a  line  segment  is  drawn  from  the  sonobuoy  to  the  submarine’s  location.  If  the  distance  is 
greater  than  1000  yards,  no  line  segment  is  drawn.  Both  of  these  situations  are  shown  in 
Figure  27,  where  the  top  sonobuoy  is  in  contact  with  the  submarine,  but  the  bottom  one  is 
not.  In  addition,  the  iconic  representation  of  the  submarine  is  not  shown.  This  is  omitted  to 
simulate  a  radar’s  inability  to  detect  subsurface  vehicles  and  to  offer  the  greater  challenge 
of  locating  the  submarine  without  knowing  any  position  information  when  the  simulation 
is  begun. 

Multiple  sonobuoys  can  indicate  contact  with  a  single  submarine.  If  one 
submarine  is  within  1000  yards  of  two  or  more  sonobuoys,  lines  are  drawn  from  each 

sonobuoy  to  the  submarine,  as  shown  in  Figure  28.  If  there  is  more  than  one  submarine 
within  range  of  a  sonobuoy,  only  the  position  of  the  closest  submarine  is  indicated  on  the 
radar  display. 

3.  Weapons  Launch 

Weapons  can  be  launched  in  NPSNET  either  by  the  person  controlling  the  host 
vehicle  in  NPSNET  or  by  the  person  operating  the  interface  Panel.  To  launch  weapons  in 
NPSNET,  the  pilot  can  either  press  the  appropriate  button  on  the  joystick,  or  press  the 
appropriate  button  on  the  keyboard.  This  functionality  was  not  changed  for  this  research. 

Changes  were  made  to  weapons  launch  functionality  in  the  interface  Panel, 
however.  To  launch  weapons  from  the  Panel,  the  buttons  labelled  ‘Torpedo”  and  “Missile”, 

shown  in  Figure  17,  are  used.  At  any  point  in  the  simulation  exercise,  the  person  operating 
the  Panel  places  the  mouse  pointer  on  the  appropriate  weapon  button  and  presses  the  left 
mouse  button.  This  sends  a  GUI_MSG_DATA  packet  to  the  NPSNET  host  vehicle,  which 
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launches  the  selected  weapon.  Since  the  ATO  has  the  responsibility  of  launching  weapons 
in  the  SH-60B,  the  Panel  can  be  used  to  launch  weapons  regardless  of  who  has  control  of 
the  host  vehicle  in  NPSNET,  either  the  person  flying  the  NPSNET  helicopter  or  the  person 
controlling  the  Panel. 

C.  WEAPONS  SIMULATION 

The  SH-60B  has  the  capability  to  carry  and  launch  Penguin  missiles  and  Mk  48  or 
Mk  50  torpedoes.  This  is  simulated  in  a  general  sense  in  NPSNET.  The  SH-60B  in 
NPSNET  has  two  weapons,  a  missile  and  a  torpedo.  The  missile,  representing  the  Penguin, 
is  a  generic  missile  that  can  home  in  on  a  targeted  vehicle.  No  functionality  was  added  to 
the  current  simulation  of  missiles  in  NPSNET  in  this  research. 

To  simulate  torpedoes,  a  new  munitions  class  was  added  to  NPSNET  to  represent 
helicopter  launched  torpedoes.  What  is  unique  about  this  kind  of  weapon  in  NPSNET  is 
that  is  has  two  separate  trajectory  calculations,  one  for  the  airborne  ballistic  phase,  and  one 
for  the  underwater  homing  phase.  In  addition,  the  torpedo  only  has  the  capability  to  home 
in  on  and  destroy  ships  and  submarines  in  NPSNET. 

When  a  torpedo  is  launched,  an  array  is  created  containing  the  identification 
numbers  of  vehicle  in  the  current  simulation  that  are  eligible  to  be  targeted,  which  are  ships 
and  submarines.  This  is  done  to  allow  a  quick  lookup  for  the  torpedo  when  trying  to  gain  a 
contact  to  start  homing  in  on  the  target.  The  torpedo  itself  follows  a  ballistic  trajectory  until 
water  impact. 

Once  the  torpedo  impacts  the  water,  the  homing  phase  begins.  If  there  are  any 
eligible  targets  in  the  simulation,  the  distance  from  the  water  impact  point  to  the  vehicle  is 
calculated.  If  any  of  these  vehicles  are  within  the  torpedo’s  acquisition  range,  defined  at 
compile  time  to  be  3000  yards,  the  closest  of  these  vehicles  becomes  the  target.  The  torpedo 
then  turns  toward  the  target.  If  there  are  no  eligible  vehicles  in  range,  the  current  distance 
from  the  torpedo  to  the  eligible  vehicles  is  checked  on  each  display  loop  in  case  a  vehicle 
enters  the  torpedo’s  acquisition  range  before  the  end  of  its  run.  If  no  vehicles  are  acquired, 
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Figure  28:  Multiple  Sonobuoy  Contact 

the  torpedo  continues  on  it  current  heading,  maintaining  its  last  calculated  pitch  and  roll 
angles. 

In  addition  to  homing  toward  the  closest  ship  or  submarine,  calculation  of  the 
distance  the  torpedo  has  travelled  since  water  impact  is  made  on  each  display  loop.  This  is 
done  to  limit  the  range  of  the  torpedo.  If  it  has  run  for  2000  yards  underwater  without  hitting 
a  target,  the  torpedo  is  deactivated. 

D.  SUMMARY 

By  adding  ASW  functionality  to  NPSNET  and  the  interface  Panel,  crew 
coordination  concepts  as  they  apply  to  ASW  can  now  be  practiced  in  simulations  over  a 
network.  The  features  added  to  simulate  ASW,  described  in  this  chapter,  provide  to  users 
the  ability  to  prosecute  subsurface  entities  in  a  realistic  training  environment.  The  interface 
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Panel,  with  the  changes  incorporated  as  a  result  of  this  research,  now  provides  the 
functionality  to  realistically  simulate  the  warfare  area  of  ASW. 
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VIII.  RESULTS,  CONCLUSIONS,  AND  FUTURE  RESEARCH 


A.  RESULTS 

The  result  of  this  research  is  a  simulation  environment  that  incorporates  real  world 
concepts  in  ASW  warfare.  From  the  standpoint  of  the  helicopter  aircrew,  realism  was  added 
to  every  aspect  of  the  simulation  to  allow  for  a  more  useful  training  environment. 

The  first  step  was  to  increase  the  realism  for  the  pilot  flying  the  ASW  helicopter.  A 
lull  set  of  flight  controls  was  implemented  to  allow  the  pilot  to  have  full  control  over  the 
helicopter.  The  model  of  the  helicopter  was  changed  from  a  simple  one  vector 
representation  to  a  more  complex  four  vector  representation.  This  model  uses  Performer  to 
manipulate  the  vectors,  so  no  speed  is  sacrificed  with  the  increase  in  complexity  of  the 
model.  This  gives  the  helicopter  the  ability  to  hover,  slide  left  or  right,  and  fly  backwards 
and  forwards.  The  realism  for  the  pilot  is  that  he  must  maintain  safety  of  flight  by 
concentrating  on  his  flying  technique,  letting  the  other  members  of  the  aircrew  handle  their 
own  responsibilities. 

Next,  the  interface  Panel  was  adjusted  to  add  realism  for  the  ATO.  By  having  the 
Panel  communicate  with  the  host  NPSNET  vehicle  through  the  GUI_MSG_DATA  packet, 
the  ATO  can  communicate  to  the  pilot  his  intentions  for  the  conduct  of  the  mission.  The 
pilot  knows  where  he  must  fly,  and  once  that  point  is  reached,  the  ATO  can  deploy  his 
sensors  and  weapons  as  necessary  to  prosecute  the  submarine. 

To  allow  for  realistic  joint  training  to  occur,  GUI_MSG_DATA  packet  filtering  by 
both  NPSNET  and  the  Panel  is  used.  This  allows  each  Panel  to  communicate  with  its  own 
NPSNET  host  vehicle.  Several  aircrews  can  prosecute  submarines  in  a  simulation,  which 
is  how  real  world  helicopter  ASW  would  be  conducted. 
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B.  CONCLUSIONS 


The  objectives  of  this  research  were  to  design  and  construct  an  interface  to  simulate 
helicopter  ASW  and  to  increase  the  realism  of  helicopter  control  in  NPSNET.  The  first 
objective  was  accomplished  by  adding  ASW  functionality  to  the  interface  Panel  and 
NPSNET.  The  second  objective  was  accomplished  by  redesigning  the  helicopter  control 
model  previously  implemented  in  NPSNET.  The  functionality  was  developed  and 
successfully  incorporated  into  NPSNET  and  the  interface  Panel.  The  following  conclusions 
have  been  reached. 

•  Complex  control  models  can  be  incorporated  into  NPSNET  which  provide  a 
higher  degree  of  realism  for  training  pilots  from  a  variety  of  airborne  platforms. 

•  Joint  training  and  crew  coordination  concepts  can  be  simulated  through  the  use  of 
a  common  interface  panel  representing  a  variety  of  vehicle  types  and  warfare  areas. 
Communication  between  the  interface  and  the  host  vehicle  can  be  isolated  so  that  they 
communicate  only  with  each  other. 

•  Simulation  of  specific  warfare  areas  is  possible  by  designing  weapons  and 
functions  specific  to  the  tactics  used  in  that  warfare  area.  Incorporating  these  into  the 
simulation  system  allows  for  realistic  warfare  training. 

C.  FUTURE  RESEARCH 

This  research  provides  a  basic  foundation  for  continued  exploration  of 
incorporating  increased  realism  in  NPSNET.  The  following  is  a  list  of  topics  for  future 
research. 

•  Continued  development  and  refinement  of  physically-based  vehicle  control 
models  in  NPSNET. 

•  Develop  electromagnetic  and  acoustic  sensor  models  and  incorporate  them  into 
NPSNET. 

•  Incorporate  acoustic  properties  into  ship  and  submarine  models  of  NPSNET. 

•  Further  optimization  of  the  network  communications  mechanisms  to  enhance 
speed  and  efficiency. 

•  Design  and  implement  a  larger  variety  of  warfare  area  specific  functions  for  the 
Panel  and  NPSNET. 
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APPENDIX  A.  SOURCE  CODE  FOR  NPSNET  IN  REMOTE 

MODE  (MAIN.CC) 


1.  #ifdef  REMOTE_P  ANEL 

2.  if  ( G_static_data->remote_exists  ) 

3.  { 

4. 

5.  if  ( (  G_remote  =  socket_read  (  &rstat ) )  !=  NULL ) 

6.  { 

7. 

8.  //NEW  -  Update  the  control  settings  only  if  the  GUI_MSG_DATA  is  to  us 

9.  if  (( G_dynamic_data->control  ==  REMOTE  )  && 

10.  (G_remote->vehicleID.address.site  ==  G_static_data->DIS_address.site)  && 

11.  (G_remote->vehicleID.address.host  ==  G_static_data->DIS_address.host)) 

12.  { 

13.  the_thrust  =  G_remote->throttleSetting; 

14.  the_joy_y  =  G_remote->joystickY; 

15.  the_joy_x  =  G_remote->joystickX; 

16.  the_gunElevation  =  G_remote->gunElevation; 

17.  the_gunAzimuth  =  G_remote->gun  Azimuth; 

18.  } 

19. 

20.  //  Update  weapons  delivery  and  fog  modes 

21.  the_button  =  G_remote->weaponsMode; 

22.  the_fog  =  G_remote->environmentMode; 

23. 

24.  //NEW  -  weapons  fire  and  FTP  info 

25.  if  ((G_remote->vehicleID.address.site  ==  G_static_data->DIS_address.site)  && 

26.  (G_remote->vehicleID. address. host  ==  G_static_data->DIS_address.host)) 

27.  { 

28.  //  If  the  helo  an  SH60,  let  the  panel  fire  weapons,  regardless  of  who  has  control 

29.  if  (isaswheloveh(draw_data->type)) 

30.  { 

31.  if  ( the.button  &  GUIJPRIMARY  ) 

32.  firebuttonhit  (  PRIMARY,  G_drivenveh,  draw_data); 

33. 

34.  if  ( the_button  &  GUI_SECONDARY  ) 

35.  firebuttonhit  (  SECONDARY,  G_drivenveh,  draw_data); 

36.  }  //end  if  ASW  helo 

37. 

38.  //NEW  -  get  FTP  data  for  display  to  user 

39.  draw_data->FTP_is_on  =  G_remote->FTPon; 

40.  draw_data->FTP_X_posit  =  G_remote->FTPXposit; 
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4 1 .  draw_data->FTP_Y_posit  =  G_remote->FTPY  posit; 

42.  }  //  end  weps  and  FTP  info 

43. 

44.  }  //  end  there  was  a  socket  to  read 

45. 

46.  //  If  the  Panel  has  control,  update  the  vehicle’s  control  information 

47.  if  (  G_dynamic_data->control  ==  REMOTE  ) 

48.  { 

49.  control_data.thrust  =  the_thrust; 

50.  control_data.pitch  =  theJoy_y; 

5 1 .  control_data.roll  =  the  _joy_x ; 

52.  draw_data->look.hpr[HEADING]  =  the_gunAzimuth; 

53.  draw_data->look.hpr  [PITCH]  =  the_gunElevation; 

54. 

55.  //  Fire  weapon  if  Panel  has  control 

56.  if  ( theJ>utton  &  GUI_PRIMARY  ) 

57.  firebuttonhit  ( PRIMARY,  G_drivenveh,  draw_data); 

58. 

59.  if  ( the_button  &  GUI_SECONDARY  ) 

60.  firebuttonhit  ( SECONDARY,  G_drivenveh,  draw_data); 

61. 

62.  if  ( thejwtton  &  GUI_TERTIARY  ) 

63.  firebuttonhit  ( TERTIARY,  G_drivenveh,  draw_data); 

64. 

65.  //  If  Panel  in  control,  toggle  targetting 

66.  if  ( (thejmtton  &  GUI_TARGETING)  !=  last_state  ) 

67.  { 

68.  G_dynamic_data->targetting  =  !G_dynamic_data->targetting; 

69.  target_ok  =  G_curtime; 

70.  last_state  =  (the_button  &  GUI_TARGETING); 

71.  } 

72. 

73.  //  If  panel  in  control,  toggle  fog 

74.  if  ( ( the_fog  &  GUIJFOG  )  !=  lastjfog  ) 

75.  { 

76.  changed.fog  =  TRUE; 

77.  last_fog  =  ( the_fog  &  GUI_FOG  ); 

78.  } 

79.  }  //  end  if  control  ==  REMOTE 

80. 

81.  //  Generate  a  GUI_MSG_DATA  packet  to  send  state  info  to  Panel 

82.  if  (  sock_open  ) 

83.  { 

84.  static  int  loop  =  0; 

85.  info_to_go.heading  =  (float)  (360.0f  -  (draw_data->posture.hpr[HEADING])); 

86.  info_to_go.pitch  =  (float)  draw_data->posture.hpr[PITCH]; 

87.  infoJo_go.roll  =  (float)  draw_data->posture.hpr[ROLL]; 
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88.  info_to_go.throttleSetting  =  (float)control_data.thrust; 

89.  info_to_go.gunAzimuth  =  (float)  draw_data->look.hpr[HEADING]; 

90.  info_to_go.gunElevation  =  (float)  draw_data->look.hpr[PITCH]; 

91.  info_to_go.positionX  =  (float)  draw_data->posture.xyz[X]; 

92.  info_to_go.positionY  =  (float)  draw_data->posture.xyz[Y]; 

93.  info_to_go.positionZ  =  (float)  draw_data->posture.xyz[Z]; 

94.  info_to_go.vehicleID.address.site  =  G_static_data->DIS_address.site; 

95.  info_to_go.vehicleID.address.host  =  G_static_data->DIS_address.host; 

96.  info_to_go.altitude  =  (draw_data->altitude)  *  METER_TO_FOOT; 

97.  info_to_go.velocity  =  draw_data->speed; 

98. 

99.  //NEW  -  info  to  send  to  panel  about  FTP  (not  really  needed) 

100.  info_to_go.FTPon  =  the_FTP0n; 

101 .  info_to_go.FTPXposit  =  the_FTPXposit; 

102.  info_to_go.FTPYposit=  the_FTPYposit; 

103. 

104.  loop++; 

105. 

106.  //  Write  the  socket  to  the  network  every  application  cycles 

107.  if  ( loop  >=  5  ) 

108.  { 

109.  socket_write  ( (char  *)  &info_to_go  ); 

1 10.  loop  =  0; 

111.  }// end  loop 

112.  } // end  if  socket_open 

113.  }  //  end  if  remote  exists 

1 14.  #endif 
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APPENDIX  B.  SOURCE  CODE  PANEL  MESSAGE  CLASS 

(MESSAGE.C) 


1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 

9. 

10. 
11. 
12. 

13. 

14. 

15. 

16. 

17. 

18. 

19. 

20. 
21. 
22. 

23. 

24. 

25. 

26. 

27. 

28. 

29. 

30. 

31. 

32. 

33. 

34. 

35. 

36. 

37. 

38. 

39. 

40. 


jj  ^^^Hf^****^*^******^*^****^*^********^  ****************  ******* 

//  Function  to  write  a  PDU  socket.  If  write  fails,  display  error  message, 

//  close  socket,  and  terminate  program. 

void  Message::writeSocket() 

{ 

//  Set  pdu  entity  address  to  the  npsnet  session  being  controlled 
pdu.vehicleID.address.host  =  G_data.npsnetAddress.address.host; 
pdu.vehicleID.address.site  =  G_data.npsnetAddress.address.site; 

if  (socket_write((char  *)  &pdu)  !=  TRUE) 

{ 

cerr  «  “socket  failure,  write  failed”  «  endl; 
cerr  «  “Exiting  program  \n”; 
socket_close(); 

exit(0); 

} 

} 


//  Function  to  read  a  PDU  socket  and  distribute  the  appropriate 
//  information  throughout  the  panel  display. 


void  Message::readSocket() 

{ 


static  GUI_MSG_DATA  *pdu_ptr; 
static  struct  readstat  rstat; 

if  ( (pdu_ptr  =  socket_read(&rstat))  ==  NULL  ) 

{ 

//  no  pdu’s  available  to  read 

} 

else 

{ 

if  ( (pdu_ptr->vehicleID.address.host  —  G_data.npsnetAddress.address.host) 
&&  (pdu_ptr->vehicleID.address.site  ==  G_data.npsnetAddress.address.site)) 

{ 
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41. 

42. 

43. 

44. 

45. 

46. 

47. 

48. 

49. 

50. 

51. 

52. 

53. 

54. 

55. 

56. 

57. 

58. 

59. 

60. 
61. 
62. 

63. 

64. 

65. 

66. 

67. 

68. 

69. 

70. 

71. 

72. 

73. 

74. 

75. 

76. 

77. 

78. 

79. 

80. 
81. 
82. 

83. 

84. 

85. 

86. 
87. 


//  update  the  throttle 
theThrottle->updateThrottle(pdu_ptr); 

//  update  the  instrument  component 

theInstrument->updateInstrumentDisplays  (pdu_ptr,  _pickVehIndex); 

//  update  the  radar  screen 
theViewscreen->updateScreen(pdu_ptr); 

//  update  the  tactical  map 
theMap->updateMap(pdu_ptr); 

} 

} 

} 


//************************************************************** 
//  Function  to  write  a  PDU  socket  based  on  throttle  movement.  First  set 
//  the  throttle  variable  in  GUI_MSG_DATA  and  then  write  the  entire 
//  socket  structure. 

y/*  ****** ******************************************* ************ 

void  Message:  :throttleChanged(int  throttle) 

{ 

pdu.throttleSetting  =  float(throttle)/100.0; 
writeSocket(); 

} 


y^* ********* *************************************** ************ 

//  Function  to  write  a  PDU  socket  based  on  gun  azimuth  movement.  First 
//  set  the  azimuth  variable  in  GUI_MSG_DATA  and  then  write  the  entire 
//  socket  structure. 

u* *********************************************** ************* 

void  Message: :gunAzimuthChanged(int  azimuth) 

{ 

pdu.gunAzimuth  =  float(azimuth); 
writeSocket(); 

} 


y^*** **************************************************** ****** 

//  Function  to  write  a  PDU  socket  based  on  gun  elevation  movement. 

//  First  set  the  elevation  variable  in  GUI_MSG_DATA  and  then  write  the 
//  entire  socket  structure. 

^/*** *********************************************** *********** 
void  Message::gunElevationChanged(int  elevation) 

{ 
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88.  pdu.gunElevation  =  float(elevation); 

89.  writeS  ocket(); 

90.  } 

91. 

92. 

93  //************************************************************* 

94.  //  Function  to  set  the  vehicle  based  on  user  selection.  Function 

95.  //  changes  the  global  value  of  the  index  of  the  selected  vehicle 

96.  //  from  the  radar  screen.  The  stealth  display  will  be  updated 

97.  //  with  the  new  value  on  the  next  timer  increment  within  the 

98.  //  readSocket  function.  No  writeSocket  is  required,  since 

99.  //  the  displayed  information  does  not  change  the  state  of  NPSNET 

100.  //  in  any  way 

101.  //************************************************************* 

102.  void  Message::pickVehicleChanged(int  index) 

103.  { 

104.  _pickVehIndex  =  index; 

105.  } 

106. 

107. 

108.  //************************************************************* 

109.  //  Function  to  write  a  PDU  socket  based  on  joystick  movement. 

1 10.  //  First  set  the  values  within  the  GUI_MSG_DATA  structure  for  the 

111.  //  joystick  inputs,  then  distribute  the  socket  to  NPSNET. 

112.  //************************************************************* 

1 13.  void  Message: :joystickChanged(float  joy stickX,  float  joystickY) 

114.  { 

115.  pdu  .joy  stickX  =  joy  stickX ; 

116.  pdu.joystickY  =  joystickY; 

117.  writeS  ocket(); 

118.  } 

119. 

120. 

121.  //NEW 

122.  //************************************************************* 

123.  //  Function  to  write  a  PDU  socket  based  on  FTP  position. 

124.  //  First  set  the  values  within  the  GUI_MSG_DATA  structure  for  the 

125.  //  FTP,  then  distribute  the  socket  to  NPSNET. 

126.  //************************************************************* 

127.  void  Message::FTPChanged(int  on,  float  FTPX,  float  FTPY) 

128.  { 

129.  //  Set  the  pdu  data  fields 

130.  pdu.FTPon  =  on; 

131.  pdu.FTPXposit  =  FTPX; 

132.  pdu.FTPYposit  =  FTPY; 

133. 

134.  //  Write  the  pdu  to  the  net 
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135.  writeSocketO; 

136.  } 

137. 

138. 

139  //************************************************************* 

140.  //  Functions  to  write  a  PDU  socket  based  on  weapon  selections. 

141.  //  First  set  the  values  within  the  GUI_MSG_D  AT  A  structure  for  the 

142.  //  weapon  inputs,  then  distribute  the  sockets  to  NPSNET. 

143  //************************************************************* 

144.  void  Message: :targettingState(short  state) 

145.  { 

146.  if  (state)  //  targetting  mode  is  on 

147.  pdu.weaponsMode  1=  GUI_TARGETING; 

148.  else  // targetting  mode  is  off 

149.  pdu.weaponsMode  &=  !(GUI_TARGETING); 

150. 

151.  writeSocketO; 

152.  } 

153. 

154. 

155.  void  Message: :primaryWeapon(short  state) 

156.  { 

157.  if  (state)  //  mode  is  on 

158.  pdu.weaponsMode  1=  GUI_PRIMARY; 

159.  else  //mode  is  off 

160.  pdu.weaponsMode  &=  !(GUI_PRIMARY); 

161. 

162.  writeSocketO; 

163.  } 

164. 

165. 

166.  void  Message: secondary Weapon(short  state) 

167.  { 

168.  if  (state)  //  mode  is  on 

169.  pdu.weaponsMode  1=  GUI_SECONDARY; 

170.  else  //  mode  is  off 

171.  pdu.weaponsMode  &=  !(GUI_SECONDARY); 

172. 

173.  writeSocketO; 

174.  } 

175. 

176. 

177.  void  Message: :tertiaryWeapon(short  state) 

178.  { 

179.  if  (state)  //  mode  is  on 

1 80.  pdu.weaponsMode  1=  GUI_TERTIARY; 

181.  else  // mode  is  off 
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182.  pdu.weaponsMode  &=  ! (GUIJTERTI AR Y ); 

183. 

184.  writeSocket(); 

185.  } 
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APPENDIX  C.  SOURCE  CODE  PANEL  RADAR  CLASS 

(RADAR.H) 


1.  fifndef  RADAR_H 

2.  #define  RADAR_H 

3. 

4.  #include  <Vk/VkComponent.h> 

5.  tinclude  <Sgm/GlxMDraw.h> 

6. 

7.  #define  MAX_FTP  6 

8.  #define  MAX.SONOBUOYS  25 

9.  #define  MAX_SONO_RANGE  lOOO.Of 

10.  #define  FTP_C  APTURE_R  AN  GE  500.0f 

11. 

12.  class  Radar :  public  VkComponent 

13.  { 

14. 

15.  public: 

16.  Radar(const  char  *name,  W idget  parent); 

17.  ~Radar(); 

1 8.  virtual  const  char  *className(); 

19. 

20.  void  updateRadar(float  posX,  float  posY,  float  hdg); 

21.  void  setRange(int); 

22. 

23.  //NEW 

24.  void  FTPState(short); 

25.  void  sonobuoyLaunch(short); 

26. 

27.  protected: 

28. 

29.  void  ginit(GlxDrawCallbackStruct  *cb); 

30.  void  expose(GlxDrawCallbackS tract  *cb); 

31.  void  resize(GlxDrawCallbackStract  *cb); 

32.  void  inputFTP(GlxDrawCallbackStract  *cb); 

33.  void  initialize_gl(); 

34. 

35.  static  void  exposeCallback(Widget  w,  XtPointer  clientData,  XtPointer  callData); 

36.  static  void  ginitCallback( Widget  w,  XtPointer  clientData,  XtPointer  callData); 

37.  static  void  resizeCallback(W idget  w,  XtPointer  clientData,  XtPointer  callData); 

38.  static  void  inputCallback( Widget  w,  XtPointer  clientData,  XtPointer  callData); 

39. 

40.  void  computeworldcoordinate(int,  int,  float  *,  float  *); 
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41.  void  monitorNet(); 

42.  void  Update_map(); 

43.  int  pickVehicle(); 

44.  void  draw_stuff_on_map(void); 

45.  void  drawBoundaries(); 

46. 

47.  //NEW  -  FTP/sonobuoy  functions 

48.  void  drawHeadingBugO; 

49.  void  drawSonobuoysO; 

50.  void  drawFTPs(); 

51.  void  deleteFTP(int); 

52. 

53.  //NEW  -  function  to  compute  the  2D  distance  between  2  points 

54.  float  computeTheDist(float,  float,  float,  float); 

55. 

56.  private: 

57. 

58.  //NEW  -  determines  whether  we  are  in  add  mode  or  delete  mode 

59.  short  FTP_add_mode; 

60. 

61.  //NEW  -  structure  for  the  FTP’s  position 

62.  typedef  struct 

63.  { 

64.  float  x_posit; 

65.  float  y_posit; 

66.  }  FTPJPOSIT; 

67. 

68.  //NEW  -  structure  for  the  FTP  information 

69.  typedef  struct 

70.  { 

71.  int  used; 

72.  FTP_POSIT  position; 

73.  }  FTPJNFO; 

74. 

75.  //NEW  -  array  to  hold  all  FTPs 

76.  FTPJNFO  FTP_array[MAX_FTP]; 

77. 

78.  //NEW  -  structure  for  the  sonobuoy’s  position 

79.  typedef  struct 

80.  { 

8 1 .  float  sono_x_posit; 

82.  float  sono_y_posit; 

83.  }  SONO_POSIT; 

84. 

85.  //NEW  -  structure  for  the  sonobuoy  information 

86.  typedef  struct 

87.  { 
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88.  int  sono_used; 

89.  SONO_POSIT  sono_position; 

90.  }  SONOJNFO; 

91. 

92.  //NEW  -  array  to  hold  all  sonobuoys 

93.  SONOJNFO  Sono_array[MAX_SONOBUOYS]; 

94.  }; 

95. 

96.  extern  Radar  *theRadar; 

97.  #endif 
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APPENDIX  D.  SOURCE  CODE  PANEL  RADAR  CLASS 

(RADAR.C) 


1.  #include  <stdio.h> 

2.  #include  <stdlib.h> 

3.  #include  <math.h> 

4.  #include  <stream.h> 

5.  #include  <iostream.h> 

6. 

7.  tinclude  “radar  .H” 

8.  tinclude  “message.H” 

9. 

10.  tinclude  “entity .H” 

11.  #include  “netutil.H” 

12.  tinclude  “global  .h” 

13.  tinclude  “fonts/fontdef.h” 

14.  tinclude  “constants.h” 

15. 

16.  //  Constants  that  define  the  GL  state  for  the  GL  widget. 

17.  static  GLXconfig  glxConfig  []  = 

18.  { 

19.  { GLX_NORMAL,  GLXJDOUBLE,  TRUE}, 

20.  {GLX_NORMAL,  GLX_RGB,  TRUE}, 

21.  { GLX_N ORM AL ,  GLX_ZSIZE,  GLX_NOCONFIG}, 

22.  {0,0,0} 

23.  }; 

24. 

25.  //  set  up  initial  radar  center  position  as  center  of  the  world 

26.  float  centerX  =  (G_data.maxX  -  G_data.minX)/2.0; 

27.  float  centerY  =  (G_data.maxY  -  G_data.minY)/2.0; 

28.  float  centerHdg  =  0.0; 

29. 

30.  static  short  pickbuffer[MAX_VEH}; 

31. 

32.  //NEW  -  variables  to  determine  which  sonobuoy  is  next 

33.  static  int  next_Sonobuoy  =  0; 

34. 

35.  float  jrange  =  1.0; 

36.  float  _posX; 

37.  float  _posY; 

38.  float  _hdg; 

39. 

40.  Radar  *theRadar  =  NULL; 
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41. 

42.  Radar:  :Radar( const  char  *name,  Widget  parent) :  VkComponent(name) 

43.  { 

44.  theRadar  =  this; 

45.  int  count; 

46.  Arg  args[10]; 

47. 

48.  count  =  0; 

49. 

50.  //NEW  -  initialize  ASW  mode  to  off 

51.  FTP_add_mode  =  0; 

52. 

53.  //NEW  -  initialize  values  for  the  FTP  array 

54.  for(int  ax  =  0;  ax  <  MAXJFTP;  ax++) 

55.  { 

56.  FTP_array[ax].used  =  FALSE; 

57.  FTP_array[ax].position.x_posit  =  O.Of; 

58.  FTP_array[ax].position.y_posit  =  O.Of; 

59.  } 

60. 

61.  //NEW  -  initialize  values  for  the  sonobuoy  array 

62.  for(ax  =  0;  ax  <  MAX_SONOBUOYS;  ax++) 

63.  { 

64.  Sono_array[ax].sono_used  =  FALSE; 

65.  Sono_array[ax].sono_position.sono_x_posit  =  O.Of; 

66.  Sono_array[ax].sono_position.sono_y_posit  =  O.Of; 

67.  } 

68. 

69.  //  replace  the  default  translation  table  for  the  GlxNinputCallback 

70.  //  with  a  new  one  that  only  responds  to  mouse  button  down  events, 

71.  //  rather  than  the  default  of  all  button  and  keyboard  events. 

72.  String  translations  =  “<BtnDown>:glxInput()”; 

73. 

74.  XtSetArg(args[count],  GlxNglxConfig,  glxConfig);  count++; 

75. 

76.  //  use  the  newly  defined  translation  table  to  replace  to  default  one 

77.  XtSetArg(args [count],  XmNtranslations,  XtParseTranslationTable 

78.  (translations));  count++; 

79. 

80.  _base  Widget  =  GlxCreateMDraw(parent,  _name,  args,  count); 

81. 

82.  XtAddCallback(_baseWidget,  GlxNexposeCallback,  &Radar::exposeCallback, 

83.  (XtPointer)  this); 

84.  XtAddCallback(_baseWidget,  GlxNginitCallback,  &Radar::ginitCallback, 

85.  (XtPointer)  this); 

86.  XtAddCallback(_baseWidget,  GlxNresizeCallback,  &Radar::resizeCallback, 

87.  (XtPointer)  this); 
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88.  XtAddCallback(_baseWidget,  GlxNinputCallback,  &Radar::inputCallback, 

89.  (XtPointer)  this); 

90.  } 

91. 

92.  void  Radar:  :exposeCallback(Widget,  XtPointer,  XtPointer  callData) 

93.  { 

94.  GlxDrawCallbackS  tract  *cb  =  (GlxDrawCallbackS tract  *)  callData; 

95. 

96.  GLXwinset(XtDisplay(theRadar->baseW  idget()),XtW  indow(theRadar-> 

97.  baseWidget())); 

98.  theRadar->expose(cb); 

99.  } 

100. 

101 .  void  Radar::ginitCallback(Widget,  XtPointer,  XtPointer  callData) 

102.  { 

103.  GlxDrawCallbackStract  *cb  =  (GlxDrawCallbackStract  *)  callData; 

104. 

105.  GLXwinset(XtDisplay(theRadar->baseWidget()),  XtWindow(theRadar-> 

106.  baseWidget())); 

107.  theRadar->ginit(cb); 

108.  } 

109. 

1 10.  void  Radar:  :resizeCallback( Widget,  XtPointer,  XtPointer  callData) 

111.  { 

1 12.  GlxDrawCallbackStract  *cb  =  (GlxDrawCallbackStract  *)  callData; 

113. 

1 14.  GLXwinset(XtDisplay(theRadar->baseWidget()),  XtWindow(theRadar-> 

115.  baseWidget())); 

116.  theRadar->resize(cb); 

117.  } 

118. 

119.  void  Radar: :inputCallback(W idget,  XtPointer,  XtPointer  callData) 

120.  { 

121.  //NEW  -  The  panel  is  in  ASW  vehicle  mode  and  new  FTP’s  are  to  be  added, 

122.  //  so  make  the  inputFTP  callback 

123.  GlxDrawCallbackStract  *cb  =  (GlxDrawCallbackStract  *)  callData; 

1 24 .  GLXwinset(XtDisplay (theRadar->base W idget()),  XtW indo w(theRadar-> 

125.  baseWidget())); 

126.  theRadar->inputFTP(cb); 

127. 

128.  //We  can’t  add  FTP’s,  so  change  the  pick  vehicle  for  stealth 

129.  theMessage->pickVehicleChanged  ( theRadar->pickVehicle() ); 

130. 

131.  } 

132. 

133. 

134  //************************************************************** 
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135.  void  Radar::ginit(GlxDrawCallbackStruct  *) 

136.  { 

137.  setRange(lOO); 

138.  initialize_gl(); 

139. 

140.  //  wait  until  the  gl  window  is  initialized  to  start  drawing  to 

141.  //  it  within  the  timer  loop,  otherwise  ...core  dump... 

142.  theMessage->_timer->start(); 

143. 

144.  //  start  listening  to  the  net  for  entities  to  display 

145.  theRadar->monitorNet(); 

146.  } 

147. 

148.  Radar:: ~Radar() 

149.  { 

150.  //Empty 

151.  } 

152. 

153.  const  char  *Radar::className() 

154.  { 

155.  return  “Radar”; 

156.  } 

157. 

158  //************************************************************** 

159.  void  Radar::expose(GlxDrawCallbackStruct  *) 

160.  { 

161.  updateRadar(G_data.world_x_size/2.0,  G_data.world_y_size/2.0,  0.0); 

162.  } 

163. 

164  //************************************************************** 

165.  void  Radar::resize(GlxDrawCallbackStruct  *cb) 

166.  { 

167.  viewport(0,  (Screencoord)  cb->width-l, 

168.  0,  (Screencoord)  cb->height-l); 

169.  updateRadar(G_data.world_x_size/2.0,  G_data.world_y_size/2.0,  0.0); 

170.  } 

171. 

172.  //NEW  -  this  designates  the  location  for  a  new  FTP 

173  //************************************************************** 

174.  void  Radar::inputFTP(GlxDrawCallbackStruct  *cb) 

175.  { 

176.  //  Variables  for  the  location  of  the  FTP  in  world  coordinates 

177.  float  wx,  wy; 

178. 

179.  //  Variable  for  which  FTP  is  the  next  to  be  input 

1 80.  int  nextFTP  =  0; 

181. 
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1 82.  //  Find  out  which  FTP  is  the  next  to  be  assigned 

183.  while  ((next_FTP  <  MAX_FTP)  &&  (FTP_array[next_FTP].used  ==  TRUE)) 

184.  next_FTP++; 

185. 

186.  if  (theRadar->FTP_add_mode) 

187.  { 

188.  if  (next_FTP  !=  MAX_FTP) 

189.  { //  one  is  available,  so  add  it;  otherwise  do  nothing 

190. 

191.  //  Call  computeworldcoordinateO  to  convert  the  screen  coordinate 

192.  //  on  the  radar  screen  to  terrain  coordinates 

193.  computeworldcoordinate((Screencoord)cb->event->xbutton.x, 

194.  (Screencoord)cb->event->xbutton.y,  &wx,  &wy); 

195. 

196.  //  Set  the  fields  of  the  FTP  array 

197.  FTP_array[next_FTP].used  =  TRUE; 

198.  FTP_array[next_FTP].position.x_posit  =  wx; 

199.  FTP_array[next_FTP].position.y_posit  =  wy; 

200. 

201.  //  the  top  priority  FTP  changed,  so  send  message  to  NPSNET 

202.  if  (next_FTP  ==  0) 

203.  theMessage  ->  FTPChanged(FTP_array[next_FTP].used, 

204 .  FTP_array  [next_FTP]  .position. x_posit, 

205.  FTP_array[next_FTP].position.y_posit); 

206. 

207.  }  //  end  if  next_FTP  !=  MAX_FTP 

208. 

209.  }  //  end  if  FTP_add_mode  on 

210. 

211.  else  //  FTP  add  mode  is  off,  so  let  the  user  pick  an  FTP  and  delete  it 

212.  { 

213.  //  Call  computeworldcoordinateO  to  convert  the  screen  coordinate 

214.  //  on  the  radar  screen  to  terrain  coordinates 

215.  computeworldcoordinate((Screencoord)cb->event->xbutton.x, 

216.  (Screencoord)cb->event->xbutton.y,  &wx,  &wy); 

217. 

218.  for(int  ix=0;ix<MAX_FTP;ix++) 

219.  { 

220.  //  If  the  FTP  got  picked,  delete  it 

221.  if  (((  wx  >=  (FTP_array[ix].position.x_posit  -  (_range/20.0f)))  && 

222.  (  wx  <=  (FTP_array[ix].position.x_posit  +  (_range/20.0f))))  && 

223.  (( wy  >=  (FTP_array[ix].position.y_posit  -  (_range/20.0f)))  && 

224.  (  wy  <=  (FTP_array[ix].position.y_posit  +  (_range/20.0f))))) 

225.  deleteFTP(ix); 

226.  }  //  end  try  to  delete  an  FTP 

227. 

228.  }  //  end  else  state 
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229. 

230.  }  //  end  inputFTPO 

231. 

232  //************************************************************** 

233.  void  Radar: :initialize_gl() 

234.  { 

235.  float  scmaspect;  //  aspect  ratio  value 

236.  long  xscmsize;  //  size  of  screen  in  x  used  to  set  globals 

237. 

238.  xscmsize  =  getgdesc(GD_XPMAX);  //  get/set  screen  size[/aspect] 

239.  if  (xscmsize  ==  1280) 

240.  { 

241 .  keepaspect(5, 4); 

242.  scmaspect  =  1.25; 

243.  } 

244.  else  if  (xscmsize  ==  1023) 

245.  { 

246.  keepaspect(4, 3); 

247.  scmaspect  =  1.34; 

248.  } 

249.  else 

250.  { 

251.  fprintflstderr,  “Something’s  EXTREMELY  wrong:  “); 

252.  fprintf(stderr,  “xscmsize=%d\n”,  xscmsize); 

253.  exit(-l) ; 

254.  } 

255. 

256.  //  Always  turn  subpixel  true. 

257.  subpixel(TRUE); 

258. 

259.  //define  the  font 

260.  fontdefllL,  G_data.hud_font_file); 

261. 

262.  doublebufferf); 

263.  } 

264. 

265  //************************************************************** 

266.  void  Radar: :monitorNet() 

267.  { 

268 .  G_data.doing  =  MONITOR; 

269. 

270.  //there  will  be  no  outgoing  PDUs 

27 1 .  G_data.net  =  RECEIVE; 

272. 

273.  //stop  generating  PDUs,  if  we  are  generating  them 

274.  for(int  ix  =0;ix<MAX_VEH;ix++) 

275.  { 
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276.  if  (G_vehlist[ix].vehptr  !=  NULL) 

277.  {  //is  it  an  active  entity 

278.  if(G_vehlist[ix].vehptr->get_C2_flag()) 

279.  { 

280.  //we  have  to  deactivate  the  vehicle 

281.  deactiveate entity(ix); 

282.  } 

283.  } 

284.  } 

285.  } 

286. 

288.  //  taken  from  the  file  inst_ptr.c  to  draw  the  artificial  horizon 

289.  void  Radar: :updateRadar(float  posX,  float  posY,  float  hdg) 

290.  { 

291.  //set  the  global  position  x  and  y  based  on  the  socket  input 

292.  _posX  =  posX; 

293.  _posY  =  posY; 

294.  _hdg  =  hdg; 

295. 

296.  //  set  the  correct  window  to  draw  the  radar  into 

297.  GLXwinset(XtDisplay(theRadar->baseW idget()),  XtW indow(theRadar-> 

298.  baseWidget(»); 

299. 

300.  //  set  the  background  color  for  the  radar  screen 

301.  RGBcolor(0, 0, 0); 

302.  clear(); 

303. 

304.  //  display  only  the  selected  range  centered  at  posX  and  posY 

305.  ortho2(_posX  -  _range,  _posX  +  _range, 

306.  _posY  -  _range,  _posY  +_range); 

307. 

308.  //  translate  (-_posX,  -_posY,  0)  to  place  origin  at  current  position 

309.  translate  (_posX,  _posY,  0.0); 

310. 

311.  //NEW  -  real  radar  screens  don’t  rotate,  so  don’ t  rotate  (heading); 

312.  //  rot(_hdg,  *z’); 

313. 

314.  //  translate  (posX,  posY,  0)  to  return  view  back  to  normal 

315.  translate  (*_posX,  -_posY,  0.0); 

316. 

317.  //  draw  radar  range  rings 

318.  linewidth(l); 

319.  cpack  (OxOOffOOOO); 

320.  circ(posX,posY,20000.0f); 

321.  cpack  (OxOOOOffOO); 

322.  circ(posX,posY,10000.0f); 


95 


323.  cpack  (OxOOOOffff); 

324.  circ(posX,posY,5000.0f); 

325.  cpack  (OxOOOOOOff); 

326.  circ(posX,posY,1000.0f); 

327.  linewidth(l); 

328. 

329.  drawBoundaries(); 

330.  Update_map(); 

331. 

332.  }  //  updateRadar(float, float, float) 

333. 

334  //************************************************************** 

335.  void  Radar: :Update_map() 

336.  { 

337.  static  int  count  =  0; 

338.  static  double  oldtime  =0.0; 

339. 

340.  //if  the  network  is  open,  update  the  time 

341 .  if(G_data.net  !=  CLOSED) 

342.  { 

343. 

344.  G_data.sim_time  =  pfGetTime(); 

345.  if  (oldtime  <  G_data.sim_time) 

346.  G_data.delta_time  =  G_data.sim_time  -  oldtime; 

347.  else  //  time  reset 

348.  G_data.delta_time  =  0; 

349.  oldtime  =  G_data.sim_time; 

350. 

351.  //move  all  of  the  icons 

352.  update_entities(); 

353. 

354.  if (G_data.net  !=  OPEN) 

355.  { 

356.  //where  are  all  of  the  entities 

357.  draw_stuff_on_map(); 

358.  } 

359.  } 

360. 

361 .  if(G_data.net  !=  CLOSED) 

362.  { 

363.  parse_net_pdus(); 

364.  } 

365. 

366.  swapbuffersO; 

367.  count  ++; 

368.  } 

369. 
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370. 

371  //************************************************************** 

372.  void  Radar:  :draw_stuff_on_map() 

373.  //  draws  the  new  and  improved  2D  map  on  the  screen 

374.  { 

375.  int  ix,  inttype; 

376.  float  pos[3]; 

377.  char  text[40]; 

378. 

379.  //use  the  pretty  pictures 

380.  font(l); 

381. 

382.  for(ix=0;ix<MAX_VEH;ix++) 

383.  { 

384.  if(G_vehlist[ix].vehptr  ==  NULL)  continue; 

385.  pfCopy  V  ec3  (pos  ,G_vehlis  t[ix] .  vehptr->getposition()); 

386.  inttype  =  G_vehlist[ix].type; 

387.  if  (inttype  <  1  ) 

388.  sprintf(text,”%c”,’  ?’ ); 

389.  else  if  ( (inttype  >=  1)  &&  (inttype  <=  5) ) 

390.  sprintf(text”%c”,T); 

391.  else  if  ( (inttype  >=  6)  &&  (inttype  <=  10) ) 

392.  sprintf(text  ,”%c”,’E’); 

393.  else  if  ( (inttype  >=  1 1)  &&  (inttype  <=  20) ) 

394.  sprintf(text,”%c”,’Q’); 

395.  else  if  ( (inttype  >=  20)  &&  (inttype  <=  25) ) 

396.  sprintf(text,”%c”,’R’); 

397.  else  if  ( (inttype  >=  26)  &&  (inttype  <=  30) ) 

398.  sprintf(text,”%c”,’C’); 

399.  else  if  ( (inttype  >=31)  &&  (inttype  <=  35) ) 

400.  sprintfltext  ,”%c”,’  ?’ ); 

401.  else  if  ( (inttype  >=  36)  &&  (inttype  <=  40) ) 

402.  sprintf(text,”%c”,’A’); 

403.  else  if  ( (inttype  >=  41)  &&  (inttype  <=  45) ) 

404.  sprintf(text,”%c”,T); 

405.  else  if  ( (inttype  >=  46)  &&  (inttype  <=  50) ) 

406.  sprintf(text  ,”%c”,T); 

407.  else  if  ( (inttype  >=51)  &&  (inttype  <=  55) ) 

408.  sprintf(text,”  %  c”,’  G  ’ ); 

409.  else  if  ( (inttype  >=  56)  &&  (inttype  <=  57) ) 

410.  sprintf(text,”%c”,’A’); 

411.  else  if  ( (inttype  >=  58)  &&  (inttype  <=  60) ) 

412.  sprintf(text,”%c”,T); 

413.  else  if  (  (inttype  >=  61)  &&  (inttype  <=  70) ) 

414.  sprintf(text  ,”%c”,’B’); 

415.  //  DON’T  PRINT  SUBS  ON  DISPLAY 

416.  else  if  ( (inttype  >=  71)  &&  (inttype  <=  75) ) 


417.  sprintf(text,”%c”,’ 

418.  else  if  ( (inttype  >=  76)  &&  (inttype  <=  80) ) 

419.  sprintf(text,”%c’Y?’); 

420.  else  if  ( (inttype  >=  81)  &&  (inttype  <=  95) ) 

421.  sprintf(text,”%c”,’&’); 

422.  else  if  ( (inttype  >=  96)  &&  (inttype  <=  99) ) 

423.  sprintf(text,”%c”,’?’); 

424.  else  if  ( (inttype  >=  100)  &&  (inttype  <=  199) ) 

425.  sprintf(text,”%c”,7’); 

426.  else 

427.  sprintf(text,”%c”,’x’); 

428. 

429. 

430.  switch(G_vehlist[ix].vehptr->getforce()) 

431.  { 

432.  case  ForceIDJBlue: 

433.  cpack(0xffff8f00); 

434.  break; 

435.  case  ForceID_Red: 

436.  cpack(OxffOOOOff); 

437.  break; 

438.  case  ForceID_White: 

439.  cpack(Oxffffffff); 

440.  break; 

441.  default: 

442.  cpack(OxffOOffOO); 

443.  break; 

444.  } 

445. 

446.  cmov2(pos[X],pos[Y]); 

447.  charstr(text); 

448.  } 

449. 

450.  //back  to  the  normal  text 

451.  font(O); 

452. 

453.  //NEW  -  this  calls  the  function  to  draw  the  heading  bug 

454.  drawHeadingBugO; 

455. 

456.  //NEW  -  draw  the  sonobuoys  and  their  bearing  lines 

457.  drawSonobuoysO; 

458. 

459.  //NEW  -  draw  the  FTPs 

460.  drawFTPs(); 

461.  } 

462. 

463  //************************************************************** 
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464.  int  Radar::pickVehicle() 

465.  //  draws  pick  map  on  the  radar  screen  to  evaluate  mouse  input 

466.  { 

467.  static  int  ix; 

468.  static  float  pos [3]; 

469 .  static  char  text[40] ; 

470.  static  int  numofhits; 

471. 

472.  //  set  the  correct  window  to  draw  the  pick  map  into 

473.  GLXwinset(XtDisplay(theRadar->baseWidget()),  XtWindow(theRadar-> 

474.  baseWidget())); 

475. 

476.  //set  up  the  pick  buffers 

477.  pushmatrixO; 

478.  pick(pickbuffer,MAX_VEH); 

479. 

480  //  ****************  Set  up  the  window  ****************** 

481.  ortho2(_posX  -  _range,  _posX  +  _range, 

482.  _posY  -  _range,  _posY  +  _range); 

483. 

484.  //  translate  (-_posX,  -_posY,  0)  to  place  origin  at  current  position 

485.  translate  (_posX,  _posY,  0.0); 

486. 

487.  //  rotate  (heading); 

488.  rot(_hdg,  ‘z ’); 

489. 

490.  //  translate  (posX,  posY,  0)  to  return  view  back  to  normal 

491.  translate  (-_posX,  -_posY,  0.0); 

492. 

493.  font(l); 

494. 

495.  for(ix=0;ix<MAX_VEH;ix++) 

496.  { 

497.  if(pos,G_vehlist[ix].vehptr  ==  NULL)  continue; 

498.  pfCopyVec3(pos,G_vehlist[ix].vehptr->getposition()); 

499. 

500.  //store  the  location 

501.  loadname((short)ix); 

502. 

503.  //figure  out  where  the  guy  is 

504.  sprintf(text,”%c”,’E’ ); 

505.  cpack(Oxffffffff); 

506.  cmov2(pos[X],pos[Y]); 

507.  charstr(text); 

508.  } 

509.  font(0); 

510. 


99 


511.  //number  of  things  picked  from  the  screen 

512.  numofhits  =  (int)endpick(pickbuffer); 

513. 

514.  if(numofhits  >  0) 

515.  { 

516.  popmatrixO; 

517.  return  (pickbuffer[l]); 

518.  } 

519.  else  //  no  vehicle  was  selected 

520.  { 

521.  popmatrixO; 

522.  return  (0); 

523.  } 

524.  } 

525. 

526.  //NEW  -  changed  from  old  code 

527  //************************************************************** 

528.  //  computeworldcoordinate  - 

529.  //  This  function  computes  the  world  coordinate  corresponding  to  the 

530.  //  input  mouse  coordinate. 

531.  //  The  input  mouse  coordinate  is  in  the  X  window  system  so  the 

532.  //  origin  is  in  the  upper  left  comer. 

533.  // 

534.  //  Inputs: 

535.  //  int  x,y  =  input  mouse  coordinate  in  X  coordinate  system. 

536.  // 

537.  //  Outputs: 

538.  //  float  *wx,  *wy  =  returned  world  coordinate. 

539.  // 

540. 

541.  void  Radar:  :computew or ldcoordinatefint  x,  int  y,  float  *wx,  float  *wy) 

542.  { 

543.  //  Find  the  world  x  coordinate 

544.  *wx  =  ((  2  *  jrange  )/324.0f)  *  (x)  +  ( _posX  -  _range ); 

545. 

546.  //  Find  the  world  y  coordinate 

547.  *wy  =  ((  2  *  _range  )/324.0f)  *  ((324.0f  - 1)  -  y)  +  ( _posY  -  _range  ); 

548.  } 

549. 

550  //***** ************************************************ ********* 

55 1 .  void  Radar:  :setRange(int  range) 

552.  { 

553.  //set  range  as  a  function  of  the  %  of  the  world  size 

554.  //NEW  -  only  show  the  shortest  distance  that  can  be  seen 

555.  if  (G_data.maxX  <  G_data.maxY) 

556.  _range  =  ((G_data.maxX  *  float(range)  / 100.0)  /  2.0); 

557.  else 
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558.  _range  =  ((G_data.maxY  *  float(range)  / 100.0)  /  2.0); 

559. 

560.  if  (_range  <  1.0) 

561.  _range=1.0; 

562.  } 

563. 

565.  //  draw  the  boundaries  of  the  world 


566.  void  Radar: :drawBoundaries() 

567.  { 

568.  static  float  p [4] [2]; 

569.  p[0][0]  =  G_data.minX; 

570.  p[0][l]  =  G_data.minY; 

571. 

572.  p[l][0]  =  G_data.minX; 

573.  p[l][l]  =  G_data.maxY; 

574. 

575.  p[2][0]  =  G_data.maxX; 

576.  p[2][l]  =  G_data.maxY; 

577. 

578.  p[3][0]  =  G_data.maxX; 

579.  p[3][l]  =  G_data.minY; 

580. 

581.  cpack(0xFF8  8 8888); 

582. 

583.  bgnclosedlineO; 

584.  v2f(p[0]); 

585.  v2f(p[l]); 

586.  v2f(p[2]); 

587.  v2f(p[3]); 

588.  endclosedlineO; 

589.  } 

590. 

591.  //NEW  -  all  FTP  functionality 

592.  //  This  function  turns  on/off  the  pick  functions  for  FTPs 

593.  void  Radar: :FTPState(short  state) 

594.  { 

595.  //  Allow  the  user  to  input  a  new  a  FTP 

596.  if  (state) 

597.  theRadar->FTP_add_mode  =  1; 

598. 

599.  //  Allow  the  user  to  pick  a  FTP  and  delete  it 

600.  else 

601.  theRadar->FTP_add_mode  =  0; 

602.  } 

603. 

604. 
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605.  //NEW  -  Draw  the  heading  bug 

606.  void  Radar::drawHeadingBug() 

607.  { 

608.  //  2x2  array  for  starting  point  and  endpoint  for  the  heading  bug 

609.  float  head_vec[2][2]; 

610. 

611.  //  This  is  the  starting  point,  the  center  of  the  display 

612.  head_vec[0]  [0]  =  _posX; 

613.  head_vec[0][l]  =  _posY; 

614. 

615.  //  The  endpoint  is  in  the  direction  of  heading,  scaled  so  that 

616.  //  it  appears  the  same  length  no  matter  what  the  range  setting  of 

617.  //  the  radar  is. 

618.  head_vec[l][0]  =  _posX  +  ((_range/5.0f)  *  sinf(_hdg  *  DEG_TO_RAD)); 

619.  head_vec[l][l]  =  _posY  +  ((_range/5.0f)  *  cosf(_hdg  *  DEG_TO_RAD)); 

620. 

621 .  //  draw  the  heading  bug 

622.  linewidth(l); 

623.  cpack  (OxOOffffff);  //  color  white 

624.  bgnline(); 

625.  v2f(head_vec[0]); 

626.  v2f(head_vec[l]); 

627.  endlineO; 

628.  } 

629. 

630. 

631.  //NEW  -  this  function  adds  a  new  sonobuoy  to  the  sonobuoy  array 

632.  void  Radar::sonobuoyLaunch(short  state) 

633.  { 

634.  //  State  is  true  so  add  a  new  sonobuoy;  otherwise,  do  nothing 

635.  if  ((state)  &&  (next_Sonobuoy  <  MAX_SONOBUOYS)) 

636.  { 

637.  Sono_array[next_Sonobuoy].sono_used  =  TRUE; 

638.  Sono_array[next_Sonobuoy].sono_position.sono_x_posit  =  _posX; 

639.  Sono_array[next_Sonobuoy].sono_position.sono_y_posit  =  _posY ; 

640.  next_Sonobuoy++; 

641.  } 

642.  } 

643. 

644. 

645.  //NEW  -  this  draws  the  sonobuoys  and  lines  of  bearing  to  the  sub 

646.  void  Radar:: drawS onobuoys() 

647.  { 

648.  // This  if  for  the  font  to  be  used 

649.  char  text[40]; 

650. 

651.  cpack(OxOOOOffOO);  //  color  green 
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652. 

653.  //  Draw  the  sonobuoys  and  their  bearing  lines 

654.  for(int  ax  =  0;  ax  <  MAX_SONOBUOYS;  ax++) 

655.  { 

656.  //  Variables  for  distance  calculation 

657.  float  dist_to_contact  =  MAX_SONO_RANGE; 

658.  float  temp_distance  =  O.Of; 

659. 

660.  //  Variable  for  which  ID  we  are  going  to  target 

661 .  int  contact_ID  =  -1 ; 

662. 

663.  //  Array  to  hold  the  endpoints  of  bearing  lines 

664.  float  bearing_line[2][2]  =  {0}; 

665. 

666.  //  Arrays  for  target  position 

667.  float  target_pos[3],  temp_pos[3]; 

668. 

669.  if  (Sono_array[ax].sono_used  ==  TRUE) 

670.  { 

671 .  //  Sonobuoy  is  the  first  point  of  the  bearing  line 

672.  bearing_line[0][0]  =  Sono_array[ax].sono_position.sono_x_posit; 

673.  bearing_line[0][l]  =  Sono_array[ax].sono_position.sono_y_posit; 

674. 

675.  //  First  draw  the  sonobuoy  symbol 

676.  font(l); 

677.  sprintf(text,”%c”,’0’); 

678.  cmov2(bearing_line[0][0],  bearing_line[0][l]); 

679.  chars  tr(  text); 

680. 

681.  //Now  draw  the  bearing  line  to  the  target 

682.  for(int  bx  =  0;  bx  <  MAX_VEH;  bx++) 

683.  { 

684.  if  ((G_vehlist[bx].vehptr  !=  NULL)  && 

685.  (G_vehlist[bx].vehptr->gettype()  ==  SUBMERSIBLE)) 

686.  {  //  this  is  a  SUB,  so  find  if  it  is  the  closest 

687.  pfCopyVec3(temp_pos,  G_vehlist[bx].vehptr->getposition()); 

688.  temp_distance  =  computeTheDist(bearing_line[0][0], 

689.  bearing_line[0][l], 

690.  temp_pos[X],  temp_pos[Y]); 

691. 

692.  //  shorter  distance  test 

693.  if  (temp_distance  <  dist_to_contact) 

694.  {  //  it  is  closer,  so  target  it 

695.  pfCopyVec3(target_pos,  temp_pos); 

696.  contact_ID  =  bx; 

697.  dist_to_contact  =  temp_distance; 

698. 
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699.  }  //  end  if  closer 

700. 

701 .  }  //  end  if  this  is  a  sub 

702. 

703.  }  //  end  search  for  closest  SUB  to  draw  to 

704. 

705.  if  (contact  ID  !=  -1) 

706.  {  //  we  have  the  closest  contact,  so  draw  the  bearing  line 

707.  //  Target  is  the  endpoint  of  the  bearing  line 

708.  bearing_line[l][0]  =  target_pos[X]; 

709.  bearing_line[l][l]  =  target_pos[Y]; 

710. 

711.  //  Draw  the  bearing  line 

712.  font(0); 

713.  linewidth(l); 

714.  bgnline(); 

715.  v2f(bearing_line[0]); 

716.  v2f(bearing_line[l]); 

717.  endline(); 

718. 

719.  }  //  end  if  we  have  a  contact 

720. 

721.  }  //  end  if  the  sonobuoy  is  to  be  drawn 

722. 

723.  }  //  end  for  all  possible  sonobuoys 

724. 

725.  }  //  end  drawSonobuoys() 

726. 

727. 

728.  //NEW  -  this  draws  the  sonobuoys  and  lines  of  bearing  to  the  sub 

729.  void  Radar: :drawFTPs() 

730.  { 

731.  // This  if  for  the  font  to  be  used 

732.  char  text[40]; 

733. 

734.  //  First  check  to  see  if  the  vehicle  is  close  enough  to 

735.  //  capture  the  #1  FTP;  is  so,  delete  and  launch  a  sonobuoy 

736.  if  ((FTP_array [0] .used  ==  TRUE)  && 

737.  ((computeTheDist(_posX,  _posY, 

738 .  FTP_array  [0]  .position.x_posit, 

739.  FTP_array[0]  .position.  y_posit)) 

740.  <=  FTP_CAPTURE_RANGE )) 

741.  { 

742.  deleteFTP(O); 

743.  sonobuoyLaunch(l); 

744.  }  //  end  capture  FTP 

745. 
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746.  //  Draw  the  FTPs 

747.  font(l); 

748 .  cpack(OxOOffOOff);  //  color  cyan 

749.  for(int  cx  =  0;  cx  <  MAX_FTP;  cx++) 

750.  { 

751.  //  Only  put  it  on  the  screen  if  it  is  active 

752.  if  (FTP_array[cx].used  ==  TRUE) 

753.  { 

754.  //  Designate  the  FTP  font  to  be  used  in  order  of  priority 

755.  if  (cx  =  0) 

756.  sprintf(text,”%c”,’4’); 

757.  else  if  (cx  ==  1) 

758.  sprintf(text  ”%c”,’5’); 

759.  else  if  (cx  ==  2) 

760.  sprintf(text  ”  %c” 6  ’ ); 

761.  else  if  (cx  ==  3) 

762.  sprintf(text,”  %c”  ,’7  ’ ); 

763.  else  if  (cx  ==  4) 

764.  sprintf(text,”%c”,’8’); 

765.  else 

766.  sprintf(text,”%c’Y9’); 

767. 

768.  //  Put  the  character  in  the  correct  radar  position 

769.  cmov2(FTP_array[cx].position.x_posit, 

770.  FTP_array[cx].position.y_posit); 

771.  charstr(text); 

772.  }  //  end  if  FTP  is  used 

773. 

774.  }  //  end  for  all  possible  sonobuoys 

775.  font(O); 

776. 

777.  }  //  end  drawFTPs() 

778. 

779. 

780.  //NEW  -  this  deletes  the  selected  FTP  and  changes  the  priority 

781.  // of  those  that  remain 

782.  void  Radar:  :deleteFTP(int  FTPid) 

783.  { 

784.  //  The  number  deleted  is  the  top  priority  FTP,  so  send 

785.  // new  message  to  NPS  NET 

786.  if  ((FTPid  ==  0)  &&  (FTP_array [FTPid] .used  =  TRUE)) 

787.  theMessage  ->  FTPChanged(FTP_array[FTPid  +  lj.used, 

788.  FTP_array  [FTPid  +  l].position.x_posit, 

789.  FTP_array  [FTPid  +  l].position.y_posit); 

790. 

791 .  //  Rearrange  the  rest  of  the  array 

792.  while  (FTPid  <  (M AX_FTP  -  1 )) 
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793.  { 

794.  FTP_array  [FTPid]  =  FTP_array[FTPid  +  1]; 

795.  FTPid++; 

796.  }  //  end  rearrange  FTPs 

797. 

798.  // Set  the  last  FTP  to  unused 

799.  FTP_array  [FTPid]  .used  =  FALSE; 

800. 

801.  }  //  end  deleteFTP() 

802. 

803. 

804.  //NEW  -  used  to  calculate  the  2D  distance  between  2  points  using  the 

805.  //  Pythagorean  theorem 

806.  float  Radar: :computeTheDist(float  from_x,  float  from_y, 

807.  float  to_x,  float  to_y) 

808.  { 

809.  retum(sqrt(((to_y  -  from_y)  *  (to_y  -  from_y))  + 

810.  ((to_x  -  from_x)  *  (to_x  -  from_x)))); 

811.  } 
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